Alex Rivera | Logout

Multi-framework NuGet build with symbols for internal dependency management

Asked 2012-10-12T21:41:45.670
20

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, beca

nuget nuget-package multiplatform
Edit
Report

1 Answer

8

You know there is a third option? When targeting a csproj file, it will also look for a nuspec file with the same name as your project file (myProject.csproj --> myProject.nuspec). This means that you can add extra metadata to the resulting package by defining it into the nuspec file, whilst still targeting your csproj file. In essence, you'll end up with a package containing the merged metadata from your csproj file and nuspec file.

In your specific scenario, if you want to package multiple platform builds of the same project, you'll indeed have to build those projects first before packaging using the nuspec.

I'd advise you to create two projects, one targeting NET35, the other one targeting NET40, and adding the files as links into one of the projects. As such you can build both projects, and package all output in one NuGet package using a nuspec file.

Now as for symbols, I think you could have a second nuspec file (myProject.symbols.nuspec for instance), where you could add all contents of the project (sources etc) using wildcard characters, similar to what's shown below.

<file src="myProject35\**\*.cs" target="src" />
<file src="myProject40\bin\Release\*.dll" target="lib\net40" />
<file src="myProject40\bin\Release\*.pdb" target="lib\net40" />
<file src="myProject35\bin\Release\*.dll" target="lib\net35" />
<file src="myProject35\bin\Release\*.pdb" target="lib\net35" />

Hope this helps or at least provides you some info to find a way out :)

Cheers, Xavier

answered 2012-10-12T22:02:58.327

Your Answer