Question

Maybe I’m pushing the envelope here, but I’m desperate to leverage NuGet to ease the DLL Hell that I’ve found myself in.

We have 4 main products that all live in interrelated Mercurial repositories. All of them “share” 3 core assemblies and then everything else is pretty much product-specific. It’s become very difficult to manage now because one product has been upgraded to .NET 4.0 and is using external dependencies that require .NET 4.0, while another product is stuck in .NET 3.5 for reasons I don’t even want to get into.

So, we have lost our ability to merge differences between products.

To fix it, I want to take out the 3 main assemblies, and turn them into their own project with their own release cycle, and take the care to make sure they can compile against both .NET 3.5 and 4.0, and then turn those into NuGet packages containing multiple framework versions.

BUT, I also want developers to be able to browse the source of these projects.

So I set up a private NuGet server and a private SymbolSource server. Then I carefully merged all the changes from all repositories together, and threw out everything except my core assemblies. Then I painstakingly hand-edited the .csproj files so that instead of the AnyCPU platform, each project has platform targets of 3.5 and 4.0, which specifies conditional constants (to control platform-specific features like System.Dynamic) and sets the framework version.

Then I set up solution configurations for “3.5 Debug”, “3.5 Release”, “4.0 Debug”, and “4.0 Release”. Each one targets the appropriate Configuration (Debug or Release) and Platform (3.5 or 4.0).

I can build everything fine within Visual Studio for any platform. Now I have a problem when it comes to NuGet, because there are two ways to create a package, and both have a weakness, unless I’m missing something:

Package by Project File

nuget pack MyProject.csproj -Build -Symbols -Version <insert-from-build-server> -Properties "Configuration=Release;Platform=3.5;"

The problems with this are:

• While the 3.5 version is built and packaged, the output says “Building projecct for target framework ‘.NETFramework,Version=v4.0’.”
• If I unpack the resulting packages, the assemblies are under lib\net40 which is wrong.
• I don’t think there is any way to package 2 framework targets this way, you have to do it the other way with folders and conventions.
• I am willing to accept that you can’t package the frameworks together and make 2 packages called MyProject (which I would do as 4.0) and MyProject.V35 … however I can’t figure out how to have the same project and nuspec and wind up with 2 different results with different ids.

Package by Nuspec File

With this method, I have to do all the msbuilding myself and then do a bunch of file copying to set up a folder structure like

* MyProject.nuspec
* net40
    * MyProject.dll
    * MyProject.pdb
* net35
    * MyProject.dll
    * MyProject.pdb

Then I can run nuget pack MyProject.nuspec but then there is no source to go with the symbols, because without the .csproj file, NuGet has no way to figure out where to get all the source files, and I don’t see any documentation on how to do this using directory conventions either.

So my questions are:

1. Is there a way to add source files to a convention-based package?
2. Is there a way to package a project-based package twice with different ids?
3. Is there another avenue that perhaps I haven’t considered?

Any thoughts would be much appreciated.

Answer 1

Xavier’s answer led me in the proper direction, and also informed my Google searching. I was not fully aware of the file declarations, and when searching along those lines, I found Joshua Flanagan’s post Tips for building NuGet packages, which is excellent. Xavier and Joshua together taught me a few things:

1. You don’t have to assemble a conventions-conforming file tree in order to build a package. It’s much better to use the file element to select files and target them to a destination directory within the assembled NuGet package.
2. NuGet’s -Symbols flag doesn’t just work for packaging on a .csproj file. When you do use it on a .csproj file, then sure, that’s how it figures out how to package up all your source files. But you can also use -Symbols on a .nuspec file that includes the source via file elements. The normal NuGet package will not include the src directory, but the Symbols package will.

So now, let me describe my build process as it occurs on my CI server:

1. Build the solution using the “3.5 Release” solution configuration.
2. Build the solution using the “4.0 Release” solution configuration.
3. Use ILMerge.exe to internalize some assemblies. I have these output to (for example) bin\Release-3.5\merged so I don’t have to monkey with renaming the target assembly to temp.dll before I use it in the merge.
4. Build the package against the .nuspec in Powershell.

Here is the package command:

nuget pack src\MyProject\MyProject.nuspec -OutputDirectory .\output -Build -Symbols -Version $Version

Note that $Version is passed in from the build server so I can use its build number as the last part of the version.

Here is the .nuspec file:

<?xml version="1.0"?>
<package>
    <metadata>
        <id>MyProject</id>
        <version>0.0.0</version>
        <title>MyProject</title>
        <authors>David Boike</authors>
        <owners>David Boike</owners>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>MyProject</description>
        <releaseNotes></releaseNotes>
        <copyright>Copyright 2012</copyright>
        <tags>my tags</tags>
    </metadata>
    <files>
        <file src="bin\Release-4.0\merged\MyProject.dll" target="lib\net40" />
        <file src="bin\Release-4.0\merged\MyProject.pdb" target="lib\net40" />
        <file src="bin\Release-4.0\MyProject.xml" target="lib\net40" />
        <file src="bin\Release-3.5\merged\MyProject.dll" target="lib\net35" />
        <file src="bin\Release-3.5\merged\MyProject.pdb" target="lib\net35" />
        <file src="bin\Release-3.5\MyProject.xml" target="lib\net35" />
        <file src="**\*.cs" target="src" />
    </files>
</package>

Note that I have removed a lot of the more informative elements from my nuspec because it just doesn’t matter for an internal project like this.

The result is a package for my private NuGet server that contains DLL, PDB, and XML documentation for the assembly for both .NET 3.5 and 4.0, and then a separate symbols package for my private SymbolServer that includes all of the above plus the source. This is very easy to view with the NuGet Package Explorer which I highly recommend you download.

Finally, I tested everything and with the Visual Studio setup suggested at symbolsource.org (except with my own private symbol server) I was able to debug the code and easily step into the source.

Thanks again to Xavier for leading me down the right path!