For creating a Private NuGet Repository – See Part 1
Creating the Packages
To create the packages themselves, you’ll need the NuGet Command Line package installed on your system (this can be installed using NuGet).
Next go to the command line and change to your project’s directory. Issue the following command…
Nuget spec MyProject.sln
… where MyProject.sln is the name of you solution file.
A nuspec file manifest should be created and look something like the following…
The dollar placeholders are populated automatically when the package is created from the information given to the assemblies. You can replace these with static fields if you would like. From here, you can simply call the following command to generate a nuget package (a .nupkg file)…
nuget pack MyProject.sln.nuspec
.. however, this tends to generate a package with all of your assemblies and content, along with any third party dependencies. Not what you’d normally want!
The way I now generate these packages is to list the files and dependencies in the nuspec file. This overrides everything and ONLY includes those files.
At this point it’s probably worth explaining the directories listed as the target attribute in the above XML. There are three main folders that NuGet uses in it’s package structure – lib, content and tools.
Content contains any content you’d like placed in the root of a project that implements your package.
Tools contains powershell script files to be run when the package is installed for the first time, every time it is installed and when it is uninstalled. I’m not going to go into too much detail about the powershell scripts, but Init.ps1 will run the first time a package is run in a given solution, Install.ps1 will run every time a package is installed on a project within a solution and Uninstall.ps1 will run when a package is uninstalled. For more info on powershell within NuGet packages see http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package
Lib contains folders with specific framework versions with dlls that will be added as a reference for projects implementing your package. Common framework versions are listed below
|.NET 4.0||net40||Just using ’40’ also works.|
|.NET 4.0 Client Profile||net40-client|
|.NET 4.0 Full Profile||net40-full||Requires full .NET profile|
|.NET 4.0 Compact Framework||net40-cf||net40-compactframework also works.|
|Windows Phone 7.0||sl3-wp|
|Windows Phone 7.1 (Mango)||sl4-windowsphone71|
Now run the nuget pack command above and the nuget package will create a file containing only the files you specify. Give the nupkg file a .zip extension and open it and you can check out what’s been created.
I hope this has been helpful. Watch this space for more .NET info.
UPDATE: “Failed to download package correctly. The contents of the package could not be verified”
We’ve run into the issue where NuGet plugin for Visual Studio reports “Failed to download package correctly. The contents of the package could not be verified” whilst updating a package. There’s a few comments on CodePlex, and I’ve come to the conclusion that this is because Nuget is requesting a version of the package, which has been cached by the client. Nuget performs some kind of hash check including the version number that it’s expecting to receive and the actual package it got, along with a hash value in the package.
To solve this issue, click on the Nuget server application in IIS and click on HTTP response headers. Select the option for “Set common headers” (in the side bar) and check “Expire Web Content” along with the “Immediately” radio button. This sets HTTP headers to tell the clients not to cache the packages.