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
Related
Our team works on a project with TFS as source control. Sometimes that I want to check-in some errors happen.
D:\CustomManager.1.0.7184.35750\lib\net461\CustomManager.dll: Could not find a part of the path 'D:\CustomManager.1.0.7184.35750\lib\net461\CustomManager.dll'.
I gotta go to the Packages folder and make a new folder. after that, I have to copy the previous version of the package in that and then rename it to solve the case. This way is a little annoying because sometimes after that, new errors will show with different versions.
Additional information: This error will only be shown when I update the NuGet packages.
Is there a simple way to fix this?
Seems you directly checked libraries(dlls) in to TFS and manage version control of them.
It's not a recommend way, there are multiple downsides such as it's never exactly clear which projects are using which versions of which assemblies. It's a maintenance nightmare.
Suggest you use Nuget to handle these libraries in TFS. You should compile your code, package it in Nuget and publish it. For multiple projects you can upgrade their nuget references when appropriate, or stick with the older versions if they need to. If you need to reference a known-good, stable version, you just make sure your project is configured to pull a specific version from NuGet.
TFS use Package Management that hosts NuGet, npm, and Maven packages alongside all your other TFS assets: source code, builds, releases, etc, also be able to handle the external packages.
You could add external packages to a TFS Package Management feed. When you restore the packages, select the feed. All need packages will be restored entirely. To achieve this, just use Push NuGet packages to specify the packages you want to publish and the target feed location.
More details please refer Get started with NuGet Package Management in TFS
Update:
Keep looking for old packages, this will not happen if you already referred the latest dll in project. Please double check this part.
In your situation, if you want to check the dll in source control, you should add dlls in the solution/project and use relative path. Otherwise, tfs server may not find path.
For cache issue, suggest you to clear TFS cache then restart VS, and check in again, this may do the trick.
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.
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
A bit of a noob question, but I'm wondering why, after I have checked in a project, other developers need to use Nuget to get all the packages I had included. Shouldn't those DLLs be in the references folder already?
Is there any strategy to make things a bit more painless? I have to go through the list of all the references and make suggestions to them about what they should attempt to pull down to make the project compile?
Regards,
Chris
If anyone stumbles over this, please have a look at Nuget Powertools. There is an option to restore Nuget packages that reconciles this issue across devs - very nice :)
With newer versions of NuGet it is possible to configure a project to automatically restore NuGet packages so that the packages folder doesn't need to be included in the source code repository. Good.
However, this command adds a new .nuget folder and there is a binary there, NuGet.exe. This can also be re-created automatically by Visual Studio and so it doesn't feel correct to add that to version control. However, without this folder Visual Studio won't even load the solution properly.
How do you people deal with this? Add .nuget to source control? Run some command line script before opening the solution?
This post is old, you should not be using solution level NuGet package restore anymore. As of version 2.7+ there is an option in the NuGet setup to automatically restore packages on build.
So the .nuget folder can be deleted and the option removed from your projects.
http://docs.nuget.org/docs/reference/package-restore
UPDATE: With the release of NuGet 4.x and .NET Standard 2.0, when you use the new csproj format you can now use package references, ironically reintroducing the dependency on msbuild to restore packages, but now packages are a first class citizen of msbuild. The link above also makes mention of the PackageReference, but the following announcement details it better:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
And the NuGet 4.x RTM announcement, which ironically isn't as useful:
https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html
UPDATE 2: Apparently with VS2017 you can even use package references with classic csproj projects, but they aren't backwards compatible anymore, and there have been some problems with restoring package sub-dependencies. I'm sure that will all be resolved.
#Richard Szalay's answer is right - you don't need to commit nuget.exe. If for some reasons Visual Studio does not automatically download the nuget.exe, make sure you have the following set to true in the nuget.targets file:
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
Close the VS solution, reopen it and build it. Visual Studio should download nuget.exe automatically now.
According to this thread, the .nuget folder should be version controlled.
You need to commit .nuget\nuget.targets, but not nuget.exe. The targets will download the exe if it doesn't exist, as long as you change DownloadNuGetExe to true in nuget.targets
Although I usually don't like the idea of adding exe's to source control, I would suggest that source control should contain anything that is required in order to open, build and execute the project.
In this case it sounds like the .nuget folder is a required dependency. Therefore it ought to be under source control.
The only question left, that you need to research, is how NuGet is going to react if that folder is marked read-only, which TFS will do once it has been checked in.
Update:
I did a little more research on this as I've never used NuGet before. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I would suggest that probably what you want to do is make NuGet a requirement that has to be installed on every developers workstation.
Further, you should place in source control the batch file required to get a workstation ready to start editing the project. The batch file is going to run the commands necessary to get and install the dependency packages.
Beyond that I'd say you might want to contact NuGet directly to ask them how, exactly, this is supposed to work.
Now that nuget supports package restoration we're looking at it more closely.
We use Subversion for source control, and my initial thoughts are that .nuget should be added to our repository, but added using svn:externals so that it points to a single location.
That way we can automatically push out new versions to all developers and projects. For projects on release branches, rather than HEAD, we can specify the revision of svn:externals reference if we want to leave nuget alone.
We have a lot of projects, so it also means not duplicating nuget.exe multiple times in the repo.
We have the nuget.config file in the folder, as it has the references to our internal Nuget server, using the Package Sources area:
https://docs.nuget.org/consume/nuget-config-settings
Apart from this reason, you should let Visual Studio handle the downloading of packages.