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

David Boike
  • 18,545
  • 7
  • 59
  • 94

3 Answers3

15

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!

SliverNinja - MSFT
  • 31,051
  • 11
  • 110
  • 173
David Boike
  • 18,545
  • 7
  • 59
  • 94
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

Xavier Decoster
  • 14,580
  • 5
  • 35
  • 46
  • When you advise to create two projects, are you saying MyProject.v35.csproj and MyProject.v40.csproj, with all of the .cs files referenced in both? The projects contain LOTS of code files and I was really hoping to avoid the management nightmare of keeping them in sync. – David Boike Oct 12 '12 at 22:10
  • Yeah.. 2 projects MyProject.v35.csproj and MyProject.v40.csproj. Use "Add as Link" when adding existing items from one project to another. It's indeed a bit of a setup, but afterwards you only need to keep track of syncing newly added or deleted files from a project. Modifications to linked items are picked up by both projects as they point to the same files. – Xavier Decoster Oct 12 '12 at 22:15
  • I really REALLY didn't want to maintain two separate csproj files. But, your answer led me toward an eventual solution. Thank you + upvote! – David Boike Oct 17 '12 at 14:45
  • 1
    In some cases you don't even have to track the files and "add them as link". In my workspace I created a central project which I always with. This project targets the latest version of the .NET framework. Projects for another versions of the .NET framework just add all the `*.cs` files from the same directory using MSBuild's wildcard feature: `` – Igor Soloydenko Jan 14 '13 at 19:06
  • 2
    FYI - Control-Shift-Drag'n'Drop copies files between projects as links – Tim Long Apr 17 '13 at 02:54
  • For building .nuget packages that support netstandard and full framework, I think this is the best option. I don't think @DavidBoike's answer would work. – pomeroy May 05 '17 at 13:32
  • @pomeroy Definitely, I did this way before netstandard was a thing. I also think that the new csproj file format in VS2017 makes a lot of this moot because it's a lot more trivial to manage 2 projects across the same set of source files. – David Boike May 08 '17 at 15:14
  • @DavidBoike I would really love to know more about that, as I've been struggling to handle this correctly. – pomeroy May 08 '17 at 17:01
  • 1
    @pomeroy The new csproj format can handle glob file patterns i.e. rather than a line for every file. Makes it a lot easier to have 2 csproj files that both include (mostly) the same set of files but build them differently. http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/#that-massive-list-of-files – David Boike May 09 '17 at 17:53
0

Check out the new features in NuGet 2.5 related to framework version dependant references: http://docs.nuget.org/docs/release-notes/nuget-2.5

It might be an option for you to use build configurations with conditional references elements in the csproj files (conditinal on the TargetFrameworkVersion), then run your build in all configurations, and produce output for net35 and net40 with optional targeting of references in your nupkg.

Mads Nissen
  • 41
  • 2