PackageReference should support DevelopmentDependency metadata

[AArnott]

msbuild /t:pack fails when building a stable versioned package that depends on an unstable one, even though that unstable one is a DevelopmentDependency:

1. Create .NET Core console app
2. Add this package reference

   <PackageReference Include="Nerdbank.GitVersioning" Version="1.5.28-rc" developmentDependency="true" />`

3. Pack the project with msbuild /t:pack

Build fails with a crashed MSBuild task with this message:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(73,5): error MSB4018:
The "PackTask" task failed unexpectedly.\r [C:\Users\andre\OneDrive\Documents\Visual Studio 2017\Projects\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(73,5): error MSB4018: System.IO.InvalidDataException: A stable release of a package should not have a prerelease dependency. Either modify the version spec of dependency "Nerdbank.GitVersionin
g [1.5.61-ga5f362ccc1, )" or update the version field in the nuspec.\r [C:\Users\andre\OneDrive\Documents\Visual Studio 2017\Projects\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj]

In fact I shouldn't even have to specify DevelopmentDependency="true" in my reference because the nuspec of the referenced package itself has that property set.

[davidfowl]

You're aiming to have this package excluded from the output package right?

[AArnott]

Correct: no dependency, no embedding.
And thus no restriction on using unstable packages while building a stable one.

[emgarten]

PrivateAssets is the equivalent.

<PackageReference Include="Nerdbank.GitVersioning" Version="1.5.28-rc">
   <PrivateAssets>all</PrivateAssets>
</PackageReference>

[AArnott]

Thanks @emgarten. Should that be a default then when the package's own nuspec sets DevelopmentDependency=true?

Also, I'm guessing that's not quite equivalent to what we have in project.json (in an MSBuild project). I can add a package dependency to a developmentDependency package and that propagates across project references (as I usually want), yet that doesn't limit my ability to compile those projects into stable packages that don't depend on it. Your PrivateAssets=all metadata suggests to me that it won't propagate across P2Ps.

[clairernovotny]

I need this as well for GitVersionTask for the same reason. The GitVersionTask nuspec has developmentDependency set to true.

When a project references it, it should default the <PrivateAssets>all</PrivateAssets> metadata on that package ref...or whatever is needed to ensure it doesn't get added to the generated nuspec with /t:pack

[davidfowl]

@emgarten we need 2 things:

• We need a way for a package to express what assets get exported when referenced in a project .e.g If I want all projects that reference me to have effectively <PrivateAssets>all</PrivateAssets> by default then I should be able to express that in the nuspec.
• We should infer developmentDependency set to true as implicitly saying <PrivateAssets>all</PrivateAssets> .

[AArnott]

Can we at a minimum for Dev15 RTW get developmentDependency=true in a nuspec file to be honored by having the dotnet SDK project type not propagate the dependency in nuget packages it packs?

[AArnott]

@davidfowl points out that PrivateAssets=all at the consuming side should workaround this issue. This is also consistent with the documentation. But I tried it, and the dotnet pack step still emits a package dependency on it (with the default exclude="Build,Analyzers" attribute no less).

[rohit21agrawal]

@AArnott pack should not emit a dependency when <PrivateAssets>all</PrivateAssets> is specified. Did you make sure you restored after you added the <PrivateAssets> tag to your dependency? Pack relies on reading the dependencies and their metadata from the assets file, so if the assets file doesn't reflect your changes, pack wouldn't know about them.

[AArnott]

Thanks, @rohit21agrawal. That was the trick. I was only running dotnet pack after my change rather than a restore as well.

[rohit21agrawal]

Great! Are we good to close this issue now?

[AArnott]

No. There's still the matter of developmentDependency being ignored that should have set PrivateAssets=all by default, which @davidfowl seems to agree with as well.

[kzu]

We're seeing this as well in .NETCore/.NETStandard projects. Adding a package reference to a development dependency does not add the <PrivateAssets>all<PrivateAssets metadata.

Repro:

1 - Create a .NETCore/.NETStandard project
2 - Add a package reference (via the NPM) to NuGet.Build.Packaging (which has developmentDependency=true)

Result: PackageReference does not have PrivateAssets metadata
Expected: same behavior as packages.config, which adds the reference as <package id="NuGet.Build.Packaging" developmentDependency="true" ...

This is a regression IMHO.

/cc @adalon @mrward @mhutch

[alpaix]

Bug 389581:[Feedback] Installing NuGet package that is marked as a development dependency doesn't add the PrivateAssets="All" attribute to the PackageReference element

[davidfowl]

Should this really be an install time action? Shouldn't it be part of the task?

[clairernovotny]

Agree with @davidfowl. This shouldn't be an install-time action, the task should set it when it reads the package meta-data during restore. A user may choose to override this by explicitly setting the metadata on PackageRef, but not sure why anyone would really do that.

[bricelam]

I think the decision to use ExcludeAssets="Runtime" has some unintended consequences. See dotnet/efcore#11437

[jainaashish]

Since we had to revert this change because of EF tools package broken with ExcludeAssets=Runtime, I'm reopening this issue. We'll bring it back in 15.8 with more validations.

[mwpowellhtx]

👍 re: @bording 's responses.

So, gentlemen, what's the bottom line here? I contend that seamlessly supporting rolling up developmentDependencies is desirable, with a minimum of files or other assets that I need to touch, whether by hand of via tooling of any kind. PrivateAssets, etc, just introduces a lower signal to noise ratio, IMO, i.e. makes it harder, not easier, to discern whether a dependency ought to be rolled up in the NuGet package.

Because logic, so to say.

[bugproof]

I tried setting developmentDependency to true and it doesn't work. Only PrivateAssets work.

[nkolev92]

@wrathofodin https://github.com/NuGet/Home/wiki/DevelopmentDependency-support-for-PackageReference