I understand that it is now possible to configure a global package directory for all projects but I noticed that NuGet also puts files in my home directory. Is it possible to configure a single repo which will be used for all projects?
NuGet introduced a new way of package management in for project.json (now deprecated) and PackageReference-based projects (default .NET Core, .NET Standard).
Instead of creating a solution-local packages folder to which all packages are downloaded and extracted (alt: repositoryPath location in NuGet.Config override), all packages are downloaded to a global location (controlled by globalPackagesFolder in NuGet.Config) which is defaulted to %userprofile%\.nuget\packages (~/.nuget/packages on linux/Mac).
The idea is that you don't have to download packages multiple times and the csproj files no longer reference all individual files but just the package. .NET Core projects also do not need to copy the NuGet packages' assets because the generated .runtimeconfig.json file specifies the location of the global cache to look up the packages at runtime, so builds can be a little bit faster.
See this question, I believe everything will be clear after that
Setting up a common nuget packages folder for all solutions when some projects are included in multiple solutions
Related
I have a solution with a packages folder checked into source control. I changed some of the projects to use a project.json file rather than packages.config for defining dependencies. The projects are all normal .csproj projects, not DNX .xproj projects. Everything seemed to be working correctly however after updating a package I noticed that the new version wasn't added to the solution's packages folder. Instead it was added to NuGet's new shared packages folder in the user profile folder.
So the question is, how do I get NuGet to use the solution's packages folder rather than the shared folder?
Approaches I've tried so far without success:
Adding global.json file in the solution folder specifying "packages": "packages"
Setting <add key="disableSourceControlIntegration" value="false" /> in .nuget\nuget.config
NuGet 3.2 added support for specifying the shared global packages folder using an environment variable, NUGET_PACKAGES. You can set the full path to an alternative global packages folder, however I discovered that if you simply set the variable to "packages" then the NuGet tools in Visual Studio will treat it as a relative path under your solution folder. That allowed me to install and restore NuGet packages using the solution's packages folder.
Unfortunately building projects then gave me errors in Microsoft.NuGet.targets, unable to locate NuGet packages. The NugetPackagesDirectory property in msbuild doesn't seem to getting set. To work around this I added the following lines in to the C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.props file:
<PropertyGroup Condition="'$(NugetPackagesDirectory)' == ''">
<NugetPackagesDirectory>$(SolutionDir)packages</NugetPackagesDirectory>
</PropertyGroup>
This will affect all solutions on the machine so an alternative would be to add those same lines in each project file or into a custom props file in the solution which you import into each project. This may also be needed for build servers too.
Although this works, the drawback is that the packages folder has a different structure, packages\<package_name>\<version>\ compared to packages\<package_name>.<version>\, and old or unused versions of packages aren't deleted after they're updated or uninstalled. Manually clearing the packages directory and then restoring required packages after any changes will achieve the same thing.
Personally this feels really hacky as it requires setting global settings for something which should be set on a per solution basis. NuGet is going to be updated at some point to support per solution package directories with project.json but in the meantime this you can use the above work around, or just stick with packages.config for the time being.
I have a solution in Visual Studio 2013 with more C# project files that have source code in common but are targeting for different platforms (.Net, WinRT, .Net Micro Framework and so on).
All the csproj files are under the same directory.
These projects use a Nuget package that is available for all the above platforms itself.
If I add this Nuget package for one of the project (ex. .Net), the package.config file is created and inside has reference to that target (ex. .Net). The package is downloaded in the packages folder.
If I try to add the same package but for a different target to another project in the solution, the UI tells me that the package is already installed. It's true because a package.config file is already there but I'd like to have the same package for a different target.
So my question is the following : how can I add the same Nuget package to all different projects but with different targets ?
Thanks,
Paolo
Unfortunately, I don't think NuGet supports your scenario.
NuGet expects the packages.config file to be in the same folder as the .csproj file. There should be a 1-to-1 relation between these files. You should create a separate folder for each project rather than keep all .csproj files in the same folder.
If you want to share code across multiple projects, the easiest way is to use the new Shared Project support in Visual Studio. Normally this only applies to Universal Projects, but there is an extension[1] that you can install that enables Shared Projects for all project types.
Simply create a new Shared Project. Add all you common code to it. Then in your platform specific projects, you can simply Add Shared Project Reference.
Since each project is now independent, NuGet will add the appropriate package.
Hope this helps. Good luck!
[1] Shared Project Reference Manager https://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450
We are migrating over to using packages and NuGet for managing our dependencies on 3rd party components. This works well when referencing packages from within Visual Studio or building on the build server via msbuild.
However there are a number of files that we would like to access in our build scripts and installers. Previously these would be in source control with a well known path, now as the version of the package that we are consuming changes so the path to the package and hence the files is changing.
Is there a simple way I can get the path to a given package? The best solution I currently have is to search for all packages.config files and extract the package version from them.
Examples of the files that we need to access are
The NUnit console executable from the NUnit.Runners package for running unit tests.
License files from various packages that we redistribute with our installer.
Using the packages.config file is a pretty good solution. NuGet itself uses two approaches:
Reading the package information from the packages.config and using that to resolve to the packages path.
Enumerating all the directories in the packages directory.
You could use NuGet.Core to do either of the above if you do not want to write the code yourself. The classes that can be used are the DefaultPackagePathResolver, the PackageReferenceFile and LocalPackageRepository or SharedPackageRepository.
One problem with the second approach is that sometimes NuGet may occasionally leave behind NuGet packages that are not necessarily referenced by a project. In that case looking at the package directories may give you the incorrect information.
The only other approach I can think of might be to read the project files looking for the assembly references. Although that would not work for a solution level package such as NUnit.Runners.
I am building an MVC4 web application with VS2012 professional with NuGet Package Manager version 2.2.31210. I have multiple projects in my solution, all sharing various packages I installed using NuGet. One of my projects is an MVC4 web application where I am using packages such as bootstrap, jquery UI, etc, all installed using NuGet.
When I clone a fresh copy of my entire solution from my repository and build my MVC4 project, the package restore feature seems to be working: it creates the packages directory under the solution direcotry and populates it will all the versions of the packages I expect to see. However, the content files do not get copied to the appropriate places in the MVC app directory. The weird thing is that it does create directories for the content, but does not copy the content files themselves.
For example, I am using the Twitter Bootstrap package which appears in the packages/Twitter.Bootstrap.2.2.2. In the MVC project a directory called bootstrap (containing css, img, and js directories) gets created in the Content directory. But, no css or js files are copied into those directories!
Does anyone have a clue what magic incantation I must utter to get the build to copy these content files from the NuGet packages directory?
This is a very common issue we are all having. I've created an MSBuild Task NugetContentRestoreTask that will do this trick for you. Run the following command in the Package Manager Console:
Install Nuget Content Restore MSBuild Targets
PM> Install-Package MSBuild.NugetContentRestore
The only thing left is to call it from your BeforeBuild Target with something like this:
Project File Targets
<Target Name="BeforeBuild">
<NugetContentRestoreTask SolutionDir="$(SolutionDir)" ProjectDir="$(ProjectDir)" />
</Target>
You can take a look at the source repo and find it on nuget.org
Additional Content Folders
This nuget only includes the default folders scripts, images, fonts, and content, it is not a recursive directory includes. For additional content subfolders - you must assign the property AdditionalFolders.
<Target Name="BeforeBuild">
<NugetContentRestoreTask SolutionDir="$(SolutionDir)" ProjectDir="$(ProjectDir)"
AdditionalFolders="less;sass;common" />
</Target>
I have found a workaround, but it is ugly. By executing the following command in the NuGet Package Manager Console: Update-Package -Reinstall all the files are indeed copied to their proper places within the Mvc project Content and Scripts directories.
Unfortunately, this is risky because you are likely to end up with the wrong versions of certain packages. For example, in my case after the command finishes executing (which takes quite a while by the way), I end up with jQuery version 1.4.4. This is way old, and I assume it must be an explicit dependency of some other package that is being updated. So it appears that the order in which the packages actually get updated by NuGet is significant (it does not appear to parse the entire dependency tree for all packages and pick only the latest versions from the union of all dependencies, which seems like it would be the preferred behavior). Rather, as the command executes I see it replacing the jQuery package several times with different versions as it works its way through all the packages and their dependencies, only to end up with a very old version.
A similar approach is the execute the Update-Package -Reinstall command explicitly for each package that is causing my problem, but this is incredibly tedious and error prone.
The NuGet Package Restore feature should yield the same result as manually executing the Install-Package or Update-Package -Reinstall command for a package, but it does not.
I don't like to have the thirdparty JavaScript files under source control either. Thats why I've followed Jeff Handley advice in http://nuget.codeplex.com/workitem/2094 to create a solution my self. I didn't go the executable way, but created a nuget solution level package which does the trick.
http://www.nuget.org/packages/Baseclass.Contrib.Nuget.GitIgnoreContent/
It's tied to git, as it automatically updates the .gitignore file.
Short description:
Ignore nuget content files in git:
Generate entries in the .gitignore file to exclude nuget content files from the source repository
Restore nuget content files before building (Automatically in VS and manually with a powershell script
I've written a blog post describing how to use it.
http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=9&mobile=0
In Visual Studio 2015 Update 1, they now support contentFiles. The caveat with this is that it only works in projects that use project.json.
In reference to the problem that you are having, there is a good blog post that explains why you see this behaviour: NuGet Package Restore Common Misconceptions.
For my projects it turned out that content files work with PackageReferences only:
Existing project with nuget references via packages.config
Installed NuGet package with content files
Build project
No content files in output directory
Conversion of packages.config to PackageReferences
Build project
Content files have been copied to output directory
IDE is Visual Studio 2017. The project is an application project which means it is in the old csproj format.
I have been using NuGet to manage my internally created assemblies for a few months, and it's working very well. I recently 'discovered' portable class libraries, which has also been great - until it's time to install the packages.
Say I have a PCL that targets .NET 4.5, SL5 and .NET for Windows Store Apps. I run nuget spec to create the .nuspec file, edit the values, package it up, and add the .nupkg to our internal feed. If I open the .nupkg file in the Package Explorer, I see one content folder under lib called portable-win+net45+sl50.
When I try to install the package from any compatible project in another solution, I get the following message:
"'Project.PCL' could not be installed because it is not compatible with any project in the solution. The package doesn't target any framework."
If I manually create the .nupkg in the Package Explorer, updating the version number, adding a lib folder for each targeted framework (not a portable folder) and added the Project.PCL.dll to each folder, I can add the package to the compatible projects in the solution. But to do this process every time I want to update a PCl is somewhat tedious (I had been creating a little .cmd file in the project root folder to quickly package and deploy).
Do other people have this problem? How can I package PCL's in the same way as other types of projects?
Note - I'm using VS 2012 Ultimate and NuGet 2.2
It sounds like maybe nuget spec doesn't work for Portable Class Libraries - that's worth starting a thread or filing an issue on the NuGet site.
However, you can also create a .nuspec file from NuGet Package Explorer. Just create the package as you already did, but then choose "Save Metadata As..." to save it as a .nuspec. Afterwards you may need to edit the source paths in the nuspec file manually, but you should be able to automate the creation of the package.
For me nuget spec and nuget pack worked fine with a portable project while creating the package and installing it on a compatible project.
Do you want to check if you have the latest nuget.exe (2.2), it can be downloaded from http://nuget.org/nuget.exe or can be updated by running nuget update -self