NuGet v3 should honor developmentDependency=true in nuspec file

[AArnott]

When a nuspec file has this tag:

<developmentDependency>true</developmentDependency>

Installing that package should cause a similar attribute to be added to the packages.config file. But when I run this command

Install-Package StyleCop.Analyzers -version 1.0.0-alpha005

to install a package with that tag, I get this in my packages.config file

<package id="StyleCop.Analyzers" version="1.0.0-alpha005" targetFramework="net452" userInstalled="true" />

[yishaigalatzer]

@emgarten note this for the uap work - need to be translated (I think the feature is supported in nuget.config already)

[davidfowl]

userInstalled="true"?

[yishaigalatzer]

@davidfowl that's a half baked idea that got in, it is pretty much a useless to mimic transitive.

[AArnott]

I've noticed that userInstalled is always set to true even when it was brought in by another package. So ya, is that going away or should I file a bug for that too?

[yishaigalatzer]

It's a fail. But we are not touching it for now. Feel free to file

[AArnott]

Done #523

[danliu]

Fixed via NuGetArchive/NuGet.PackageManagement@0abe373 and NuGetArchive/NuGet3@7ca1b26

[yishaigalatzer]

Re-opened as follow up item for UWP

@anurse

[analogrelay]

We only need to consider this when we start packaging project.json based projects as packages. In theory, DNX may be considering a similar feature, so NuGet should co-ordinate with this. The only behavior this feature provides is the following:

1. A package may have "developmentDependency=true" in it's nuspec
2. When installed, that marker is preserved in the packages.config (now project.json)
3. When the project is packed, the developmentDependencies are NOT added as dependencies of the produced package.

So this only applies to implementing nuget pack on project.json projects.

[AArnott]

This still doesn't work for packages.config scenarios. My repro is with NuGet 3.0.60605.535 and D14Rel 23004.00

1. Create C# console app
2. install-package nerdbank.gitversioning -pre

It creates a package.config file that is missing the developmentDependency="true" attribute

[danliu]

@AArnott, looks like you are using the VSIX from the dev branch and the fix was not in it yet, due to recent build issues. Once we update the VSIX of dev branch, you should see the fix.

If you install latest NuGet from 3.0-rtm branch now, the issue is fixed.

[danliu]

reassign to @anurse

[danliu]

Re-opened as follow up item for UWP

[kzu]

Reopening since this is still happening for project.json-based PCLs and CPS projects.

Repro on VS015 Update 3 with NuGet 3.5.0 RTM:

• Create a .NETCore class library or a PCL that targets .NETStandard
• Install the IFluentInterface nuget package, which has the developmentDependency flag
• Check the resulting project.json: it does not have anything that flags the dependency as a development dependency.

/cc @emgarten

[yishaigalatzer]

I don't think we want to fix it in PJ, but we should fix it in package ref if needed

[kzu]

Since package ref seems like it's going to be an MSBuild 15+ only feature, I think this must be fixed in PJ. There's very little chance that NuGetizer can work properly if there's no support for this.

/cc @mhutch

I'm happy to send a PR that fixes it if someone points me in the right direction.

[kzu]

/cc @migueldeicaza this is a blocker for proper NuGetizer support on VS2015.

[kzu]

Solved in NuGetizer by allowing easy removal of inferred package references.

[bbowman]

@kzu Just for my understanding here, there is nothing "wrong" with having a developmentDependency tacked on to the produced package except that its extra baggage right? I assume that it would be mostly harmless unless a brought in dev dep conflicted with a build environment for some reason?

[kzu]

@bbowman think about something like GitInfo/GitVersion: why would you want that to propagate? The fact that you are using it for versioning your assemblies shouldn't dictate what your package consumers use for versioning theirs