Last week, we saw how to publish a simple NuGet package. When installed into your solution in Visual Studio, that package would copy some text files into the target project. That's convenient, but it isn't a typical use case for NuGet. Instead, you usually want to publish compiled assemblies, and you want installation to add those assemblies to the target project's list of assembly references.
In Recognizing Covariance Issues in Your Code, I introduced my hobby project, Parsley. This project has gotten fairly stable in recent weeks, and I decided to publish it so that I could use NuGet to install it in other projects.
In the simple NuGet package, we created a *.nuspec file containing a
files tag. That
files tag listed the files we wanted to copy into the target project upon installation. We described the target path starting with "content":
Parsley's build script generates a *.nuspec file with a slightly different naming convention for the target paths:
Starting these paths with "lib" instead of "content" indicates to NuGet that they are libraries and should be added to the target project's list of referenced assemblies. The "net40" folder is also a part of the naming convention, indicating that the assembly was built for .NET 4.0. If we're targeting several different runtimes, we could include them all in one package using folder names like "net11", "net20", etc...
Above, I'm also copying the *.pdb files into the package. Next week, we'll see a better alternative to enhance the debugging experience for your library's users: integrating with SymbolSource.org.