I'm trying to figure out a) if I'm going about this in the right way and b) how to update a solution level nuget package.
The core problem is that when a package is installed at the solution level (rather than in any particular project) and you try to update it, it doesn't remove the old reference. It just adds a new package reference, and imports both version. Which typically means (what with how powershell modules work) that the earlier powershell modules override the newer ones.
So what I have to do is uninstall the package and re-install it, which grabs the newer version. Seems inefficient.
Also, I can't seem to install or uninstall a solution level package from console. I have to do it with the Manage Nuget Packages utility, which I hate to use.
Here is some background on what I'm doing, if it helps:
I've set up a system at our company of using solution level nuget packages to add custom powershell script modules to the solution, as well as some more generalized scripted solutions I've written (like deleting TFS work items or changing a project name on the file system as well as within code).
So one project might have the DataServiceUtilities package and another would have the FrontEndUtilities package.
So, how can I update these packages without it adding two references? And can solution level operations be done in the Package Manager Console, which always defaults to targeting a project?
It appears that some of this comes from bugs in the Package Manager GUI tools, and Nuget in general
The Package Manager GUI tool doesn't handle updates properly for solution level packages. But if you run Update-Package from the package manager console it will correctly uninstall/re-install the solution-level package.
As for installing from command line, if a package has only a tools folder and no dependencies you can run install from command line and it sill install in the solution and ignore the default project.
However, as of now (Nuget 2.8) Nuget has a bug in it that causes it to treat solution-level packages with dependencies on other solution-level packages as project-level packages. It's apparently been in for about a year, and they claim it will be fixed in VS 2015. You can see the bug here: https://nuget.codeplex.com/workitem/3642
What this means is you cannot currently create a solution-level package with ANY dependencies. Please note that this is legal according to the documentation. Hopefully it will be fixed next year.
*Update
Just a quick update. It appears that in VS 2015 they have deprecated (or, more accurately, removed) solution level/tools only packages. After some out outcry they also decided to re-implement them in a future version, but it may be awhile before they do so.
Progress on re-implementing the feature can be found here: https://github.com/NuGet/Home/issues/1521
Discussion on how to work around the missing feature can be found here: https://github.com/NuGet/Home/issues/522
Related
I recently successfully switched all of our projects over to automatic NuGet restore. To do this I followed this guide. Everything worked great, I was able to delete my /packages folder and restore to my heart's content.
One of the steps in that guide says to edit your .csproj file and remove the EnsureNuGetPackageBuildImports related element.
The problem I am having now is that, after going in and downgrading one of my projects libraries, NuGet seems to have automatically added the EnsureNuGetPackageBuildImports related element back into my .csproj file.
Is there some other setting I should be changing to prevent NuGet from doing this? I would rather not have to edit my .csproj file every time I make a NuGet related change.
Is there some other setting I should be changing to prevent NuGet from doing this?
I`m afraid the answer is not if you going in and downgrading one of your projects libraries.
The target "EnsureNuGetPackageBuildImports" is used to ensures that the imported .props or .targets files are indeed imported in the old way "Enable Package Restore". NuGet has supported NuGet MSBuild support since NuGet 2.5.
Since Nuget 2.7+, Microsoft has dropped support for the 'Enable NuGet Package Restore' in VS2015 and you need to do some manual changes to either migrate old solutions or add the feature to new solutions. Nuget Automatic Package Restore has changed in Nuget 2.7+. Unfortunately, it looks like a non-backward compatible change. We have some developers on 2.7 and before who will now need to upgrade to 2.7+. In this case, NuGet will automatically added the EnsureNuGetPackageBuildImports related element back into your .csproj file when you going in and downgrading one of your projects libraries.
To resolve this, we advice that do not mix 'old' and new methods for automatic package restoration(Remove that files when you use automatic package restoration).
Besides, if going in and downgrading one of your projects libraries is unavoidable, there is a PS script can help you remove it more convenient:
DisableNuGetPackageRestore.ps1
Our VS2013 solutions contain a solution folder called .nuget, containing the files NuGet.config, NuGet.exe, NuGet.targets. What is the significance of this folder and what uses the files? Is it related to the "enable package restore" feature?
If I install or update a package (via the "Manage NuGet Packages" UI or package manager console), does this involve running the above NuGet.exe, or something else? VS is telling me that the NuGet Package Manager is up to date (via the Extensions and Updates dialog), however the above NuGet.exe is quite old. I've also found a very old NuGet.exe file in C:\Program Files (x86)\NuGet\. What uses the latter, and what are the implications of these exes being out of date?
The reason I ask is that we've been having problems with a couple of solutions over recent weeks. We can't update NuGet packages - the operation fails with the message "Error: An item with the same key has already been added". I'm trying to track down the cause, and wondering if these out of date NuGet.exe files might have something to do with it.
As far as I remember this folder is useless now with the latest nuget extension to Visual Studio. It was used before and was nothing but pain in the ass. I am not 100% sure about 2013, but in 2015 all works fine without it, so my suggestion is to update to the latest available nuget extension version and try to delete the folder, most likely everything will work.
Now packages go to current user folder, and use the config from %AppData%\NuGet\NuGet.config. For NuGet 2.6 or earlier, this setting was available in a project-specific .nuget\nuget.config file.
You can read more about it here.
So nuget is gradually getting better and easy to use without too much thinking of all this "magic" folders and stuff.
We have a complex Visual Studio solution with projects referencing the same NuGet packages of different versions.
I feel this is a bad practice, as potentially can lead to dll hell
So - is there a way to control this?
Ideally it should be a part of either:
solution build
TFS gated check-in
delivery pipeline in whatever CI\CD tool is used.
I really liked Package Manager Console Powershell Reference. But I couldn't find a way to use those cmdlets (Get-Package and Get-Project -All) in external Powershell script outside of VS.
The simplest solution I see is to write a custom Powershell script, which reads .sln file, gets all the projects and for each of them reads packages.config and takes all nuget packages versions from there.
Or ... use a VS DTE to simplify this job, but so far I didn't have an experience of using it.
And then ... once we have this script - we can run it in CI.
Is there a simpler \ more standard way of doing this?
You should not worry about multiple components referencing different versions of packages. NuGet was built to cater for this scenario.
With DLL hell, you had no idea if A.DLL could work with a new version of B.DLL. But with NuGet the dependency is specified explicitly with a range of compatible version numbers.
The version resolution used by NuGet is to always pick the lowest version of a dependency that fits in the range.
Read here for details, it explains it well:
http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html
At least as far as nuget is concerned, nuget can install different versions of packages in different projects. That said it's not advisable. As to which packages get restored it looks at the packages file (XML) anything in the file will get restored.
This file can get out of sync depending on how the package references were removed from the project/solution.
I was wondering about the right way to do this. For example, let's say you have a number of projects (part of a solution) that uses boost. Let's say you want to put the boost package in the solution so the entire thing is more portable.
How do you do that? Do you install boost in a directory within the solution? Can you reference it using relative directories, so it isn't portable?
Under Linux, for completeness, one could just store a tarball in the code under control, but it was left to the developer to bring it out and install it. I'm wondering how this is done (best practices) under visual studio.
[NOTE: I understand this might make the solution large, but the benefit would be a development environment that would run immediately without a bunch of package installs for each development system accessing the code.
In this case you could use the nuget package manager in visual studio to add the nuget boost package to your solution then boost will be available to the projects that need it. You can then enable package restore so that whenever the solution is built if the boost files are missing from the solution then nuget will restore them on build.
If you haven't already you will need to install the nuget package manager plugin for visual studio.
Where the package isn't available on nuget there are a number of options; you can build the package and then reference the assembly that's been built - you just store assemblies you need in a references directory. If your using source control software Svn or tfs possibly git ( I don't know) then you can store these in source control and then include them in the target solution via links. The final option I can think of is you can build the package into a nuget package and then store the result in your own private nuget store visual studio allows for this. Which solution works for you will depend on the size of the project, development team and the source control software you use.
I have various Nuget packages installed to my solution. Some in my domain project and some in my MVC Front End project.
This all works quite happily. However if you get the project new from source control I can see I have all the packages in the packages folder. However they all appear to have an exclamation after them in References for the projects.
If I use nuget command nuget install .\ProjectFolder\Packages.config it seems to install the pacakges again but the refrences still don't appear. I have to manually install them using nuget manage references and install them individually. Which is a bit of a hassle for new developers starting projects.
Seems a bit odd? Is something wrong or is this normal? Shouldn't Nuget/VS2010 know that all packages exist and be happy as the packages are all in the local file system from source control (I know there is a debate about keeping them there but lets leave that aside)
Thanks
Graeme
Updated June 28, 2014
You might consider a reinstall of your packages. See this thread: How do I get NuGet to install/update all the packages in the packages.config?
Leaving the outdated answer below for history, but note that the MSBuild-based package restore is currently considered a bad practice (more info: http://www.xavierdecoster.com/migrate-away-from-msbuild-based-nuget-package-restore)
Outdated answer below:
Not a direct answer to your question, but maybe a valuable suggestion when using NuGet with TFS.
You might consider the no-commit strategy for NuGet packages, and use the NuGetPowerTools Enable-PackageRestore command.
More info here:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html
http://www.xavierdecoster.com/post/2011/07/18/Continuous-Package-Integration-NuGet-vs-Source-Control.aspx
http://www.xavierdecoster.com/post/2011/10/17/tell-tfs-not-to-add-nuget-packages-to-source-control-aspx
Install NuGetPowerTools package and then Enable-PackageRestore from the Package Manager Console. That should fix it.
This is the short version of #Xavier response :).
I'm guessing it isn't normal. I removed the entire packages folder. Re-added all packages to my solution and then committed all the changes.
It now it seems to work if I re-get the site from source control. Maybe something was corrupted. The project was originally started before I was using source control and nuget. Maybe some sort of initial setup issue.
Thanks
Graeme