Duplicate Key for Different Frameworks

Topics: General
Mar 21, 2015 at 8:13 AM
Edited Mar 30, 2015 at 6:46 PM
I have two .csproj files that build the same DLL, but they point to different frameworks (.net 4.0 and .net 4.5). In the folder containing one of the .csproj files, I inserted a nuspec that has a "dependencies" section that covers both frameworks so that I can make a single NuGet package for both.

Using NuGet 2.8.3, when I "pack" against the .nuspec file directly, it works as expected. But when I "pack" against the .csproj file (in the same folder as the nuspec) I get the following error:
An item with the same key has already been added.
This is bad because my .csproj defines a number of properties that are needed in the nuspec file. In order to "pack" against the nuspec directly, I had to hard-code many values in the nuspec. I'm trying to avoid that, so I would like help to resolve this "duplicate key" issue associated with packing a .csproj which has a multi-framework nuspec defined.

My Nuspec contains this:
  <group targetFramework="net45">
    <dependency id="Microsoft.AspNet.WebApi.Client" version="5.2.3" />
    <dependency id="Microsoft.AspNet.WebApi.Core" version="5.2.3" />
    <dependency id="Microsoft.Net.Http" version="2.0.20710.0" />
    <dependency id="Newtonsoft.Json" version="6.0.8" />
  <group targetFramework="net40">
    <dependency id="Microsoft.AspNet.WebApi.Client" version="4.0.30506.0" />
    <dependency id="Microsoft.AspNet.WebApi.Core" version="4.0.30506.0" />
    <dependency id="Microsoft.Net.Http" version="2.0.20710.0" />
    <dependency id="Newtonsoft.Json" version="4.5.11" />
If I remove either of the above framework sections, whether net40 or net45, then I can successfully "pack" against the .csproj file and accordingly obtain replacement tokens I can use in the nuspec file.

The combination of successful scenarios, as opposed to the one unsuccessful scenario, suggests this is a bug in NuGet. If yes, it there a work-around? If no, what mistake is being made?

This is probably the same problem shown here, and here neither of which have been answered.