I've got problem with version of dependency that I set manually.
Note: I use Automatic restore within Visual Studio.
When I set Version="1.3.12.5" for my dependency in packages.config I expect that restore will install package and it will be referenced in next build I trigger. But it is not true. Package is installed and placed in packages directory but build does not use this downloaded packages (as csproj is not changed automatically).
Do you know possible scenarios to workaround this problem?
I tried to use Proget Client Tools but it turned out that it is not possible to use local directory feed with this. I need local and remote feeds support also, so it is additional requirement.
So, paraphrasing my question is...
How to easily change referenced version of package without touching csproj? (which is hard to edit in visual studio) Editing version twice (one in packages.config, two in csproj) is also an overkill.
Remember Package Restore simply downloads the package to the packages folder. It does not update project references as NuGet expects that the package had previously been installed. It's simply downloading the missing package files.
Package Restore is not a replacement for Install-Package. You can specify a specific version when installing. This will add the project references properly.
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 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
When other developers get the vs.net 2013 solution from TFS, Nuget doesn't seem to work as expected and many of the individual projects in the solution do not have the required dll's downloaded (although they are defined in the packages.config file).
If I go to view the installed packages, it shows up as they are installed and the correct projects are selected.
I went into console and ran:
Update-Package -Reinstall
After doing this, my packages.config file was truncated for whatever reason and 80% of my packages were removed from the config file!
What should I be looking into as it is either I have setup the solution incorrectly or nuget just isn't reliable.
Thoughts?
First of all make sure that NuGet Packages Restore is turned ON.
This forces to restore missing binaries directly from NuGet server. You can right click on Solution and enable this option as follow:
Make sure that .nuget folder that contains nuget.exe is created under your Solution.
You'll want to make sure that you have automatic package restore turned on in VS 2013. You can do this in the options.
Then, when you build, VS should grab the packages for you. If you want to manually restore the packages or do it from powershell, you'll want to use the command nuget.exe restore in the folder your solution lives in.
If you're using custom package sources, you'll want to make sure you specified them in your nuget.config file.
I've got a packages.config file checked into source control. This specifies the exact version of the Nuget dependency I want. We have our own NuGet repository. We are creating these NuGet packages ourselves.
<packages>
<package id="Dome" version="1.0.0.19" targetFramework="net45" />
<package id="Dome.Dojo" version="1.0.0.19" targetFramework="net45" />
</packages>
These packages have some JavaScript files which when you add the Nuget package as a reference in Visual Studio are copied to the Scripts folder in the project.
I don't want to check these JS files in to source control, I just want to check in the packages.config file.
When my project builds in Team City (or when I build in Visual Studio after a fresh checkout) it doesn't copy the JS files from the NuGet package. There's a question here explaining a similar problem:
NuGet package files not being copied to project content during build
But, the solution in the answer to that question doesn't work for me; that solution uses ReInstall, which is problematic because it can automatically upgrade the version in the packages.config file (say if a dependency is specified as a >=).
The whole point of this is that I want to be able to checkout a revision from my source control, and build that version with the right dependencies AND I want to use the nice packaging features of NuGet. So, I don't want any "automatically update to the latest version during the build."
There's an issue against NuGet (http://nuget.codeplex.com/workitem/2094) about NuGet files not restoring content files. And it's Marked as Closed By Design.
Thinking about how this works a little more, it appears to me (but I'm not 100% sure) that for assemblies NuGet has a different behaviour - it doesn't copy them into the project, instead it references them from the location in the packages folder. It strikes me that js files in the NuGet package should be referenced analogous to how dlls are referenced.
Is there a way to construct a NuGet package so that it references the JS as links in the project (in a similar way to how you can add an existing File as a Link in VS)? And would this solve my problem?
If not then I'll take the advice given by Jeff Handley when closing ticked Nuget Issue 2094 mentioned above:
The option you'd have is to create a new console executable that
references NuGet.Core, and you could build a supplemental package
restore for your own use that copies package contents into the
project.
Writing my own command line tool to copy the contents does seem like I'm pushing water uphill here - am I doing something fundamentally wrong?
The underlying problem here is Visual Studio's relatively poor support of JavaScript projects and JavaScript's lack of built-in module loader.
For C#, when you install a package it adds a reference in your .csproj file to the assembly on disk. When you build, MSBuild knows to copy the thing referenced to the bin directory. Since you aren't checking in your bin directory, this all works great.
Unfortunately for JavaScript, the build system isn't nearly as matured and there aren't well defined guidelines for NuGet to follow. Ideally (IMO), Visual Studio would not run web sites directly from your source directory. Instead, when you built it would copy the JavaScript files, CSS and HTML files to a bin directory from which they would be executed. When debugging, it would map those back to the original JavaScript or TypeScript files (so if you make a change it isn't to a transient file). If that were to happen then there is now a well-defined build step and presumably a well-defined tag for JavaScript files (rather than just "content"). This means that NuGet would be able to leverage that well-defined MSBuild tag and package authors could leverage the NuGet feature to do the right thing.
Unfortunately, none of the above is true. JavaScript files are run in-place, If you did copy them to bin on build Visual Studio would do the wrong thing and editing from a debugger would edit the transient files (not the originals). NuGet therefore has no well-defined place to put files so it leaves the decision up to the package author. Package authors know that the average user is just going to be running directly from source (no build-step) so they dump files into the source folder where they must be checked in to version control.
The entire system is very archaic if you are coming from a modern ecosystem like C# where someone took time to think these things through a bit.
What you could do is create an MSBuild task that, before build, would go through all of your packages, look for content, and copy that content to the desired location. This wouldn't be terribly difficult, though would take a bit of work.
Also, package authors could include a build-task that does this in their package so that before-build all of their content was copied local. Unfortunately, if only some package authors do this then you end up with weird fragmentation where some packages need to be committed to version control and others do not.
When a package is installed into a project, NuGet in fact performs these operations,
Download the package file from source;
Install the package into the so called packages folder, which is $(SolutionDir)\packages by default;
Install the package into the project, which consists of adding references to DLLs, copying content files into the project directory etc.
When a package is restored, only the first two steps are executed. Projects will not be touched by nuget package restore. Which is why the js files in your project will not be "restored".
The only solution for now is to check in the js files in your project.
If you are the owner of the package then you could use the nuget package i've created to be able to have a folder called "Linked" in the package and have a simple Install.ps1 and Uninstall.ps1 (one liners) to add every file in the nuget package's linked folder as existing to the project.
https://github.com/baseclass/Contrib.Nuget#baseclasscontribnugetlinked
I didn't try out how publication treats linked files, the problem is debugging the Project, as the JavaScript files will be missing in the directories.
If you are using git as source control you could try my nuget package which ignores all the nuget content files and automatically restores them before building.
Step by step example in my blog: http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=9&mobile=0
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.