Allow packages to state they should be installed as development dependencies by default


Certain packages, e.g. StyleCop.MSBuild should be installed as development dependencies in 99.99% of cases.

Currently, the only way to change a package installation is to manually edit the packages.config file after installing the package. It is easy to forget to do this and it is error prone.

There should be a way to change the default installation type of a package to being a development dependency.

One possible solution is to add an element to nuspec, e.g.
The resulting nupkg would contain this data and when the nuget client sees this it will add the corresponding attribute in packages.config.

file attachments

Closed Jan 3, 2014 at 10:18 PM by danliu
verified using latest 2.8 nuget.exe


deepakverma wrote Sep 5, 2013 at 12:32 AM

looks like you are looking for http://docs.nuget.org/docs/release-notes/nuget-2.7#Development-Only_Dependencies feature that is implemented in NuGet 2.7

** Closed by deepakverma 09/04/2013 4:32PM

adamralph wrote Sep 5, 2013 at 6:29 AM

@deepakverma I know about that feature. If you look carefully at the link you've posted you can see that I contributed it ;-).

This feature is a follow up enhancement which builds upon the current feature. @jeffhandley has asked me to join the NuGet team design meeting later today to present it to the team. Can you please reopen?

dotnetjunky wrote Sep 5, 2013 at 6:58 AM

Yup, this is a different feature. Re-open it.

deepakverma wrote Sep 5, 2013 at 7:23 AM

Ah, sorry about that.

JeffHandley wrote Sep 5, 2013 at 6:44 PM

@AdamRalph is going to take this on.

dotnetjunky wrote Sep 12, 2013 at 10:48 PM

Waiting for pull request from Adam.

deadlydog wrote Sep 19, 2013 at 6:04 AM

In the meantime I've blogged a work around that the package author can use to ensure that their package is installed as a development dependency. Check it out at http://blog.danskingdom.com/have-your-nuget-package-install-itself-as-a-development-dependency/.

adamralph wrote Sep 19, 2013 at 7:02 AM

@deadlydog nice work! I'm glad to hear you're finding the developmentDependency feature useful.

adamralph wrote Sep 28, 2013 at 3:31 PM

I've sent a pull request for this issue.

danliu wrote Jan 3, 2014 at 1:01 AM

verified that it works with nuget.exe pack to generated project-level packages. see attached package it created.

After installing the attached package, the developmentDependency="true" is added to packages.config such as:

<?xml version="1.0" encoding="utf-8"?>
<package id="devdependencydefault" version="1.0.0" targetFramework="net45" developmentDependency="true" />

danliu wrote Jan 3, 2014 at 1:02 AM

one thing though, is that if the package created by nuget.exe does not contain any lib or content files, it will be treated as a solution-level package and will not add the developmentDependency="true" attribute to solution-level packages.config.

adamralph wrote Jan 3, 2014 at 9:57 AM

That's interesting regarding the solution level package.

It's not a problem since the developmentDependency attribute is redundant for solution level packages. The purpose of the attribute is to convey information to the nuget pack command when used against a .csproj so it only has relevance in the packages.config for a project, and not in the packages.config for a solution.

It may be worth mentioning in the documentation that adding developmentDependency="true" to the nuspec for a solution level package has no effect.

Qube wrote Feb 1, 2014 at 4:08 AM

This is a great feature and a perfect fit for code quality tools like JSLintNet.MSBuild.

Unfortunately it looks like we can't upload a <developmentDependency> package to NuGet.org yet. I've filed a bug for it here:

adamralph wrote Feb 1, 2014 at 8:16 AM

I'm glad you like the feature! I happen to look after StyleCop.MSBuild which is why I was motivated to introduce this. It's a shame about the gallery issue, I hope that gets addressed soon so I can also update StyleCop.MSBuild.

danliu wrote Feb 5, 2014 at 6:35 PM

Sorry for the package upload issue. We're currently working on the fix and will deploy the fix to gallery soon.

Qube wrote Feb 10, 2014 at 12:43 AM

The NuGet.org upload issue is sorted and I was able to release JSLint.NET for MSBuild 2.0.0-beta.

I'm guessing NuGet 2.8 will be needed to install a developmentDependency package, otherwise users will get the same parsing error. But hopefully that'll just encourage people to get onto the latest version.

Thanks Adam, Dan et al.

danliu wrote Feb 11, 2014 at 6:49 PM

@Qube, you can specify the minClientVersion attribute in your package's metadata, to require that the minimum client for installing your package is 2.8.0.

This way NuGet will handle it gracefully and pop users to update their NuGet clients.

For details about minClientVersion, please refer to http://docs.nuget.org/docs/release-notes/nuget-2.5.

adamralph wrote Feb 11, 2014 at 7:17 PM

+1 for minClientVersion, that will ensure users of your package get the developmentDependency attribute in their packages.config.

How will older clients handle the new metadata in the package? IIRC minClientVersion was introduced in NuGet 2.5. Would I be correct in assuming that clients 2.5, 2.6 and 2.7 won't throw an error if there is new metadata in the package which they don't understand?

Qube wrote Feb 15, 2014 at 1:05 AM

Thanks for the tip regarding minClientVersion. I've updated the nuspec with that attribute in the latest JSLint.NET for MSbuild.