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:
lib\net40
which is wrong.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:
Any thoughts would be much appreciated.
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:
.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:
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..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!