nuget pack doesn't support nuspec group elements

[skofman1]

The nuspec used:

<?xml version="1.0"?>
<package >
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
    <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <description>$description$</description>
    <copyright>Copyright 2016</copyright>
    <tags>FirstTag SecondTag</tags>
    <language>en-us</language>
   <!-- <references>   
       <reference file="DepDepLib.dll"></reference>
    </references>-->
<frameworkAssemblies>
  <frameworkAssembly assemblyName="System.ComponentModel.DataAnnotations" targetFramework="net40" />
  <frameworkAssembly assemblyName="System.ServiceModel" targetFramework="net40" />
</frameworkAssemblies>
<dependencies> 
<group targetFramework="sl30">
      <dependency id="Microsoft.Net.Http1" version="2.2.29" />
      <dependency id="bootstrap1" version="3.3.6" />
      <dependency id="DepPackage1" version="1.0.0" />
</group>
<group targetFramework=".netframework45">
      <dependency id="Microsoft.Net.Http" version="1.2.29" />
      <dependency id="bootstrap" version="1.3.6" />
      <dependency id="DepPackage" version="2.0.0" />
</group>
</dependencies>
  </metadata>
  <files>
    <file src="FilesFolder\*.*" target="FilesFolder\$id$" /> 
    <file src="EmptyFolder\*.*" target="EmptyFolder" /> 
  </files>

</package>

In the resulting package, appeared a flat list of dependencies.

[yishaigalatzer]

@toddm this should be bumped above other items on your list (to make 3.4 command line RTM)

CC @emgarten

[toddm]

This bug does not happen when packing from a nuspec file only. It only happens when packing from a project file with a nuspec file. The same bug was in NuGet 2.8.6 and 3.2.0 so moving it out from 3.4 RTM.

[MichaelKetting]

I've just got hit by this, too, while trying to get a pacakge ready for .NET Core. Is this issue up for grabs?

[toddm]

Can you describe the issue you're hitting? Packing a csproj file right now can only target one framework because that's what MSBuild supports at the moment. If you've built for multiple frameworks before packing, you could change your nuspec to include all of the needed files and then pack the nuspec directly instead of the project file (pass the nuspec file in as the argument to pack instead of the project file or no argument). Another choice would be to pack a project.json file because it supports what you probably need. When we have XPlat MSBuild support, NuGet pack will need to support dependency groups. But I'm not sure I see the need at the moment. Feel free to try to convince us otherwise if you have a compelling reason, though.

[MichaelKetting]

Hi Todd! Certainly, but I'll have to elaborate a bit: I'm developing a framework split into several solutions, with the dependencies between the solutions solved via NuGet packages. At this point it's 7 solutions (I think) and 50+ projects that result in NuGet packages, but those numbers are ever growing. To keep things sane, I have a (very elaborate) build script which I have also packed as a NuGet package and am sharing/reusing across all my solutions. The script takes care of my entire build and release process, from building to testing to git-branching/tagging and maintaining my issue tracker. The upside of this approach is that I can maintain a consistent build setup quite easily. The downside is that the build script must be able to handle all scenarios I need and i can't just start from scratch if something doesn't fit. So far, that's not been an issue.

Some of the required NuGet scenarios:

• install/uninstall powershell scripts in the NuGet package of several of my projects -> This prevents me from using project.json, since those hooks have been dropped. I need those scripts to link content files into the project (instead of copying them) and as far as I can tell, this isn't supported by NuGet.
• automatically including the referenced projects as dependencies without needing to specify them in the nuspec file -> This prevents me from packing the nuspec file directly since project dependencies aren't resolved when packing a nuspec file.
• I share the nuspec file as a template across most of my projects to prevent duplication. Some of those are metadata elements I can't include via assembly attributes (e.g. licenseUrl, projectUrl) but more important, content file includes. You see, I have only a small set of package types, e.g. domain, web, or tools, so this scales very well for me.

Now, for actual project (projects) in question: I have currently 2 solutions which outpout NuGet packages that use multi-targeting and I do use a very customized nuspec file in those cases, so it isn't an issue for me to maintain a custom dependency list in this one case. Plus, I intend to autogenerate that list eventually.

Anyway, I can see that it would be a problem to merge the project dependencies with the nuspec dependencies since once you go 'group', you can't go back. The easiest thing to do would be to detect if a group is being used in the nuspec file and then merge the project dependencies into the correct group/create a new group that matches the target framework of the project. This way, it would still be possible to use project dependencies but to also supply a customized dependency list, giving the developer the most flexibility.

As for the future:

• I am considering my options for when xproj/project.json is merged back into csproj and xml (https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/). Dependening on the features/design of VS15 and it's ecosystem, I might be able to utilize the dotnet Core build/pack process in the future.
• Towards this, I'll be creating a feature request to support file linking, too, but that's for another thread :)

Best regards, Michael

[heaths]

@toddm The problem is that nuget provides an easy mechanism for sharing data in the form of certain assembly attribute values to nuget properties like $id$, $description$, $version$, etc. If we pack the .nuspec, we lose all that and have to build our own mechanism in MSBuild to pass all that through. With larger solutions, this becomes increasingly difficult trying to keep something generic. Throw in the lack of an official (and license-compatible) T4 NuGet package, and you have a real PITA for developers who want to focus on their code - not the hassles of build definitions.

For example, we have one project that builds out for both "net35" and "net45" support and has different package dependencies. We only pack the "net45" .csproj but reference the build output of the "net35" so we use dependency groups that are ignored. Now we're hitting this, too. Completely altering our project common imports or switching to something like NuProj isn't feasible at this time (we have to redo a bunch of stuff and are preparing to release, so it would be risky).

[rrelyea]

@rohit21agrawal - please analyze for 4.0 vs Future

[rohit21agrawal]

@rrelyea I think this should be fixed for 4.0 as this is definitely not the desired behavior. However, this would technically be classified as a breaking change, so we might need to come up with a good strategy to avoid any compat issues.

[dsplaisted]

From @rrelyea on #4461

but it seems like this request won't be very common and can be achieved by using a nuspec. So closing this issue.

I think we may want to use this by default in the .NET SDK for the NETStandard.Library reference. If you target .NET Standard you'll get an implicit reference to NETStandard.Library 1.6.0. If you reference a package which depends on NETStandard.Library 1.6.1, then you'll get package downgrade warnings. So I'd like to make the NETStandard.Library dependency not be included in the package (PrivateAssets=all), but it helps with compatibility for projects targeting .NET Framework and possibly Xamarin. So what I'd really like to do in the SDK by default is to have the NETStandard.Library dependency only occur in a dependency group for net45 and Xamarin platforms if necessary. In order to do that we would need this feature.

[nkolev92]

At this point, with the pack SDK, I don't believe this issue is as impactful anymore.

Multitargeting is support with dotnet pack.

Based on that, I'm gonna close this issue. Let me know if you disagree, we'd be happy to reconsider.