Separate Packages.XXX.Config for Each Framework

Topics: General
Mar 21, 2015 at 9:21 AM
Edited Mar 30, 2015 at 7:23 PM
I would like help understanding a new feature in NuGet 2.8, and how it is meant to be used.

The release notes for nuget 2.8 state the following:
When developing applications for multiple target platforms, it is common to have different project files for each of the respective build environments. It is also common to consume different NuGet packages in different project files, as packages have varying levels of support for different platforms. NuGet 2.8 provides improved support for this scenario by creating different packages.config files for different platform-specific project files
This feature appears to correspond with a new "PackagesProjectConfig" property defined in a revised NuGet.targets file. The property is defined as:
The only "face value" benefit of this capability is that I can now have multiple project files defined in the same folder (targeting different frameworks), and each can have its own packages.X.config file. But now the questions begin:
  • What is the benefit of having multiple project files defined in the same folder? If the output of each build is a DLL called "HelloWorld.dll", then each needs to be targeted to a different $TargetName$ bin folder. This sounds like a tedious manual adjustment I must make in each .csproj file. Why would I want to do this? What am I gaining?
  • Does this facilitate creating a single NuGet package that contains the targets for each framework? If no, then what is the point of this? If yes, then how is this better than simply having each targeted framework be a project in its own directory, which is the Visual Studio default behavior?
  • Does the "pack" command in NuGet 2.8 have an inherent ability to "see" all these X.csproj and package.X.config files simultaneously, so that it can auto-generate a multi-framework NuGet package?
  • Is there an assumption that I will hand-create a .nuspec file that aggregates all contents of the package.X.config files into a "dependencies" section? If yes, then doesn't that nearly negate the value of this packages.X.config feature?
The example of NuGet package files given in the release notes looks like this:
  • packages.reactiveUI.config
  • packages.reactiveUI_Monoandroid.config
  • packages.ReactiveUI_MonoMac.config
  • packages.ReactiveUI_Monotouch.config
  • packages.ReactiveUI_WP8.config