I have a Visual Studio project which I have committed to VisualSVN (via the VisualSVN => Commit menu in Visual Studio). I have added a number of libraries to this project via NuGet.
My colleague has downloaded the project I have uploaded to SVN (via VisualSVN => Get solution from Subversion...) and has found that these libraries are missing, and he is having to re-download them.
A few questions:
Is this by design? Or have I not committed my Solution properly? Or has my colleague not download the solution to his machine properly?
If this is by design, what is the correct way to re-add references to a solution downloaded from an SVN server? I am worried that I may have added a reference and worked with it, and that it may have been updated since so whenever my colleague re-adds the same reference via NuGet he will get a more up to date version that will be different, and this will break my program. Is this a valid concern?
Yes, this is by design. The whole concept of using Nuget is that you will not have to keep libraries in your version control system.
You need to Right Click on your solution in Visual Studio and select Enable NuGet Package Restore.
This will configure the solution to restore the NuGet packages (if any missing, or in case of none) whenever you'll do a build. Also, all the libraries that you've added for a particular project will have an entry in the packages.config created in the project's source drectory; for eg:
<packages>
<package id="jQuery" version="1.8.3" />
</packages>
This way NuGet makes sure everybody gets the same version.
Just enable "Nuget package restore" in your solution and packages will be automatically downloaded during the build:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
Related
I am finding it a common issue where when I download a .NET repo from Github, the solution has missing references. See an example below. When using Nuget Package Manager, it says the packages are installed already. The packages folder is missing.
I tried using 'Update-Package -reinstall' and got a bunch of lines with 'No package updates are available from the current package source for project 'project name'.... That's probably due to the missing package files.
I can fix each reference manually but it's a time consuming process. Is there a way to force fix all these references in all the projects in one swoop using a command or a tool that 'cleverly' knows what to do? I am using Visual Studio 2019 16.3 preview 1
In VS2019, those .net core projects or .net standard projects use PackageReference instead of packages.config format to manage nuget packages. And in this way, the content in xx.csproj looks similar to this:
<ItemGroup>
<PackageReference Include="FluentValidation" Version="8.1.3" />
<PackageReference Include="MediatR" Version="6.0.0" />
<PackageReference Include="AutoMapper" Version="8.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.3" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="2.2.0" />
</ItemGroup>
Every time you download a project which uses packageReference format, you only get the xx.csproj and related source files but without nuget packages. So when you open and load the solution or project in VS IDE, it will display the nuget packages name in solution explorer but with yellow warning triangle since now VS can't find those packages locally.
Is there a way to force fix all these references in all the projects
in one swoop using a command or a tool that 'cleverly' knows what to
do?
Just like what zivkan said in his answer, NuGet is normally configured to restore packages automatically if you've enabled those two options. Every time when we load the soultion in IDE, it will automatically restore the packages for us. Not sure the reason why it seems not to work in your machine, but you can check and try:
1.Go Nuget Package Manager=>Package Sources, make sure you've set https://api.nuget.org/v3/index.json as one the Available Package sources.
2.Right-click the solution in Solution Explorer, choose the Restore Nuget Packages to restore packages for whole solution.
3.Or you can Unload and reload the project to check if it helps.
4.By default, the packages are stored at C:\Users\xxx\.nuget\packages folder, you can check if those folders exists there.
(I delate all packages in that folder, so it's clear when I open the git solution in VS, the nuget is installing those necessary packages automatically, I'm not sure if there's any possibility that cause too many packages are being installed,so it will take some time? I check and find, to restore necessary packages for NorthWind solution, it require packages for over 370 MB)
I tried using 'Update-Package -reinstall' and got a bunch of lines
with 'No package updates are available from the current package source
for project 'project name'.... That's probably due to the missing
package files.
And for the reason why Update-Package -reinstall not work well in the project, maybe it's a similar issue like nuget issue #4103, for the packagereference in xx.csproj, several commands for now are not supported.
And after my check in my machine, the command obviously do not work for a PackageReference-format .net standard project. When I've installed related packages successfully, I run this command but only get No package updates are available from the current package source for project xxx, then I delete the installed packages, clean the cache and run the command again, I still get same message!
So I think this command can't recognize PackageRefernece format in .csproj, no matter whether I install related packages or not, it will always throw message No package updates are available ...
NuGet is normally configured to restore packages automatically. See the options page. The second Package Restore option, "Automatically check for missing packages during build in Visual Studio" is enabled by default on clean installs.
Here's a little video I recorded of what happens on my machine when I open the solution. Keep an eye out on the status bar at the bottom left of the window.
If your installation of Visual Studio does not behave in the same way with the automatic restore option enabled, then there is some other issue on your machine, but we don't have enough information from your question, as of the time I wrote this.
I installed a new NuGet package on my machine to get a library installed. This means I have other versions of the .NET compiler and so on. When I then push the project to my branch and others checkout and pull it, I assume their NuGet packages are different versions than mine. How do I get those to update on their machines, without doing Install NUGET_PACKAGE again, overriding everything I've done (like removing unnecessary folders)? Example:
Before:
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
After:
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.2\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.2\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
1.0.0 to 1.0.2.
This is handled by NuGet restore.
The other developers do not need to reinstall the NuGet packages into the project. All the other developers need to do is restore the packages for the projects you have modified after they have checked it out.
If they are using Visual Studio 2015 the restore will generally be done when you build the project. There is also a Restore NuGet Packages menu if you right click the solution in the Solution Explorer if you want to manually trigger the restore.
I'm training 5 people on using Visual Studio. They've mapped their drives and have "downloaded" the solution from TFS which contains 10 projects. All located at the same depth in TFS folder structure. When the new folks download the solution there's one project that doesn't get the NUGET references even though the Package folder (created by NUGET) is at the same depth of the other 10 projects when viewed in TFS.
We know how to add these manually but is there a way to automatically have VS do it? Why would only one project lose it's reference with the Package Folder right there?
It seems you are still using MSBuild-Integrated package restore approach. If NuGet recognizes that the MSBuild-Integrated package restore approach is enabled for the solution, Automatic Package Restore is skipped.
You need to migrating MSBuild-Integrated solutions to use Automatic Package Restore, then the packages will be restored automatically.
In addition, you need to update you NuGet manager to the latest version in VS Tools--Extensions and Updates. And make sure Visual Studio is configured to 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in Visual Studio' in VS Tools--Options--NuGet Package Mnager--General.
To Fix:
Unload all projects first, then right click and select edit project.
Find this line:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Comment it out.
Reload all the projects and compile.
This applies to Nuget api version 2.
Note you may configure all projects for Nuget at the solution level.
The package manager for the solution presents a set of check boxes for every project along with the buttons (Install or Uninstall).
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.
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.