I am trying to work out how NuGet knows what packages it needs to restore (and how it knows where to find them) in the case that they are not present locally (i.e. when the packages have not been committed to source control).
I can see in the solution I have a .nuget directory but that basically just contains the NuGet.exe. There's a packages.config in each project, that looks promising, that contains the following (shortened for clarity);
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="AutoMapper" version="2.2.1" targetFramework="net40" />
</packages>
I was expecting to see a URL pointing to the source of the package. So if Nuget just uses the package id string, how would it know what to do if I had multiple package sources that both list available the same package Id. Is it just through the priority in the package sources?
I ask because I have a package from a local source, I deleted the packages and disabled the package source, cleaned the solution and rebuilt. It worked when I expected it would fail.
Many thanks.
There are 2 questions in your post, so I'll try to address one by one:
How NuGet knows what packages it needs to restore?
As you guessed, Nuget uses the .Nuget folder to automatically install missing packages. Inside the .Nuget folder, there is a file named "Nuget.targets" which is basically a VS project file (.csproj) containing this line
<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" -nocache $(RequireConsentSwitch) -solutionDir "$(SolutionDir) "</RestoreCommand>
which takes the charge to install packages listed in packages.config file in each projects.
So if Nuget just uses the package id string, how would it know what to do if I had multiple package sources that both list available the same package Id ?
In %appdata%\nuget.config, you can see a list of "package sources" for Nuget: for a given packageId, Nuget will search for it in these package sources in the same order as in nuget.config
Related
We are looking to use Nuget to share code between repos.
I have created a Nuget package which contains all of the source code in a specified sub directory.
In 7Zip I can explore it and see all of the files are present.
I need to import it into another project, maintaining the directory structure so the project can build, be debugged etc.
So I have:
../repo/applications/CommonCore
But CommonCore comes from the imported nuget package.
When I import this Nuget package no files seem to be present and there is no obvious way of controlling which directory it would go to.
I have read about using the contentFiles tag to specify all of the source files but this is infeasible for me as there are hundreds of files in various subdirectories so I attempted to use a format like:
<contentFiles>
<files include="Fabric\*.*" buildAction="Content" copyToOutput="true" />
</contentFiles>
and
<files>
<file src="*.*" target="contentFiles\Fabric" />
</files>
But this has not helped.
Am I misunderstanding how Nuget works? Or have I just implemented it incorrectly?
NuGet packages are designed for binary dependencies, so the normal thing to do here is build the code from one repo, publish the resulting binaries (not the source code) in a NuGet package, then reference that package from your other project.
You can include whatever you like in a NuGet package so it is possible to add source files, but trying to use them as a way of doing source dependencies isn't what they're designed for.
I would like to use NuGet to avoid adding a 3rd party executable to git repository.
I have a NuGet package with executable published to our NuGet source. Package contents:
content\SetupFiles\bigexecutable.exe
I've added the NuGet reference to the project in which I want to use the executable. It properly adds the
SetupFiles\bigexecutable.exe
to the project directory during the NuGet package installation. But if I delete the file from the project directory it is not replaced during the build.
Is it possible that NuGet would verify if the package contents are present before the build and reinstalled the package if something is missing?
Your .exe is being added to the project since you are including it in the Content directory. NuGet will not restore items into the project. It will only restore items into the packages directory.
An alternative would be to create a tools NuGet package where the .exe is not added to the project but is available in a tools directory relative to the solution's directory.
The NUnit.ConsoleRunner is one example of such a NuGet package where it has all its .exe files in the tools directory. Using the tools directory does not cause NuGet to add any files to your project.
We have a custom NuGet package which contains a DLL and a config file. We make use of NuGet package restore so our packages are not commit in to Perforce. When the package is installed to the solution it adds a reference to the DLL and the config file is included in the root of the project. Both of these are desirable, but should the config file be checked in to source control?
Our CI environment breaks when the file is not checked in, but the package has been downloaded correctly. It looks like this is the correct NuGet behaviour, but I'm not sure what the suggested best practice it is with regards to content files and how they should be treated in version control. Do all content files added from packages need to be checked in?
NuGet package restore will only restore files into the packages directory.
Files that are copied into your project when installing a NuGet package should be checked into source control since they will not be restored.
I created a nuget package (let's name it Web.Content) with lots of js, css and other content for my other package (named Web). In nuspec file I had file section
<file src="Content\**\*.*" target="content\Content" />
I made changes in some files from Content folder, then I created a new version of Web.Content package.
I have a project that includes Web and Web.Content packages. After a new version of Web.Content package was created I updated it in my project via nuget. When I try to commit changes of my project, SVN suggests me to commit all content of Web.Comment package.
As I understand, when nuget package was updated all target folder "content\Content" was deleted and copied from package again.
But I need SVN to trace only changes that were made in a couple of files, I don't want to see thousands of changed files because actually changes were made only in some of them.
How can I make nuget copy only changed files? Should I change my nuspec file or should I create some PS script for my package that will override delete'n'copy nuget package update behaviour?
It will be great to have some examples or links.
Tried with NuGet 2.6.40627.9000 and Tortoise SVN 1.7.7.
As far as I understand NuGet copies files during package installation using somу VS API. This API makes SVN think that the file was deleted and a new file was added(probably this happened because VisualSVN or AnkhSVN is installed).
So we decided to do the next steps:
Place our content items in our own folder which name differs from
"Content"(let's name it "fs_content") because the presence of such
folder in package triggers NuGet usual installation behavior, but
we don't need NuGet to install our content in usual way.
Write own install.ps1 script that copies our content files to
destination and put it into Tools package folder.
But after installing such package our content items did not appear where they should appear. My colleague googled some information in NuGet help - "The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off." We placed a dummy file into "Content" folder and Install.ps1 script began to copy our content from "fs_content" folder as we want.
Now SVN determines only changes made in some files correctly.
I have started creating NuGet packages for some frequent dependency projects we used to use svn:externals for in our ASP.NET solutions. I'm hosting the .nupkg files in a network folder, and using that folder location as a NuGet feed.
I'm unsure what files to place in version control and where. Do you put both the .nuspec AND the .nupkg files in your repository? Do both the .nuspec and .nupkg file go in the project's version control? I thought since the .nuspec file generates the .nupkg file, you'd only need that file in version control. But, I was also thinking it might be a good idea to make the network folder, that I'm using as a NuGet feed, a repo in itself. Then I can version control the .nupkg files.
What are some good practices for version controlling created NuGet packages?
I'm in the same place you are. In keeping with the idea that you don't commit any file that you can build, my .nuspec files go in version control, but the .nupkg files don't.
Since the version number is incorporated into the .nupkg file name, you can have distinct versions of the package in the repository at the same time. You either need to either use the <version>$version$</version> form in the .nuspec file, and set the assembly version to auto-increment, or just manually change the version number each time. You could then make a Subversion tag on that version number, so you could get back to the source for a particular package version if you need to.
In order to let client projects automatically incorporate minor bug fixes in our packages, we're going to enable NuGet Package Restore in the client projects, and publish packages with short, fixed version numbers, like "1.2". When there's a simple bug fix for the package, we'll re-publish with that same version number. That will overwrite the prior version in the repository; client projects will then get the update when they restore packages during the build step.