When using nuspec / csproj pair, provide a way to exclude package dependencies


The default behavior of nuget pack is great when its called against a csproj. It will look at the corresponding nuspec and packages.config files and it will automatically include dependencies.

However, not all dependencies are runtime dependencies. Some dependencies are build-time tools type dependencies.

I don't see a convenient means of excluding a package dependency that doesn't need to ship with the resulting nupkg file.

I would like to see this added as a feature. A simple means of excluding dependencies in the .nuspec file would suffice.
Closed Jul 16, 2013 at 11:30 PM by murilorocha


Iristyle wrote Feb 22, 2012 at 3:42 PM

Looks like there was some discussion on this here as well -- http://nuget.codeplex.com/discussions/282251

drewmiller wrote Feb 27, 2012 at 5:30 PM

@Iristyle, yeah, this is broken. You should be able to add an explicit <dependencies> section to the .nuspec to override the implicit behavior of looking at package.config, just like you can explicitly override the metadata that comes from the project by setting values in the .nuspec. But I just tested that and it's not working.

JeffHandley wrote Feb 28, 2012 at 12:00 AM

This is a candidate for package authoring enhancements in 1.8.

adamralph wrote Jun 7, 2012 at 10:11 AM

Bump! Yes please...

jrummell wrote Jun 14, 2012 at 6:42 PM

The workaround I'm using is to pack my .nuspec instead .csproj and pass in replacement values with the -Properties switch:

nuget pack foo.nuspec Version 1.5 -Properties Configuration=Release

It's not ideal, but my CI server can still handle it.

adamralph wrote Jun 28, 2012 at 7:35 AM

@jrummell - nice, I may look at doing this myself for some of my builds. I guess one drawback is that I have to pick out all the replacement values from the assemblies in order to plug them into the command line. I guess that may not be too difficult though.

Unfortunately it won't work for some of my builds because they contains lots of project with lots of dependencies which are needed. So for those I really need the exclude feature so that I can just worry about the dependencies which I don't need.

Bump to any developer with this issue on radar... ;-)

brockbouchard wrote Sep 4, 2012 at 6:09 PM


I am also experiencing this problem. I am running Nuget 2.0 and even when I list explicit dependencies, it seems to be merging them with implicit dependencies when packing against a csproj. I will likely have to switch to packing against a nuspec for now.

Besides the dependency exclude approach explored here, what do folks think of indicating some kind of "package type" concept? This way something like StyleCop.MSBuild could write to packages.config as <package id="StyleCop.MSBuild" type="CodeOnly" />, and "nuget pack" could be smart enough to ignore such dependencies. It would keep the developer universe from having to remember to exclude :)



adamralph wrote Oct 30, 2012 at 5:07 PM

Bump! Development time wasted again here today and the root cause was someone forgetting to hack out a package from packages.config in order to avoid the package being brought in as a dependency. So infuriating.


dcazzulino wrote Nov 15, 2012 at 6:50 PM

+1. annoying not being able to exclude this behavior :(

adamralph wrote Jan 14, 2013 at 10:40 PM

why close the issue? why not leave it open so it can be tracked and stil be recognised as something that needs doing, even if it's not going to be done by the core team?

MariusFili wrote Jan 15, 2013 at 1:59 PM

The problem is very annoying since I have to use csproj files in our company. And I cannot disable the implicit dependencies... :-( Please open the case again!

dcazzulino wrote Jan 15, 2013 at 2:57 PM

Closing the issue just because you're not going to fix it now, looks like typical Microsoft backlog management like the one we've seen for years on Connect: keep the backlog small so upper management is happy, even if that involves alienating customers by closing things that shouldn't be closed.

This is clearly NOT the way to go for an open source project. (or any project, if you ask me ;)).

Keep it open, let the community work on it if it's annoying enough to motivate contributors.

dotnetjunky wrote Jan 15, 2013 at 7:27 PM

Reopen because we do want to accept pull requests from community.

adamralph wrote Jan 19, 2013 at 3:36 PM

I'm attempting to code this feature by using a new optional 'exclude' attribute on the dependency element in the nuspec file.

My current problem is that the tests fail with "The 'exclude' attribute is not declared."
at NuGet.Manifest.<ValidateManifestSchema>b__11(Object sender, ValidationEventArgs e) in e:\Code\Personal\nuget\src\Core\Authoring\Manifest.cs:line 267

I guess this makes sense, since it's validating the document against http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd

I'm not sure how to proceed. Can I point it at my own version of the XSD somehow?

adamralph wrote Jan 19, 2013 at 3:49 PM

ah, got it - they're being mapped in code to \src\Core\Authoring\nuspec.xsd

adamralph wrote Jan 19, 2013 at 6:16 PM

adamralph wrote Jan 20, 2013 at 10:46 AM

I've opened http://nuget.codeplex.com/discussions/430179 to discuss a possible solution to this.

adamralph wrote Jan 22, 2013 at 10:35 PM

corresponding docs pull request https://github.com/NuGet/NuGetDocs/pull/59

johncrim wrote Jan 24, 2013 at 6:41 AM

Enhancement to the current proposal detailed here:


In summary, each package dependency needs 2 new attributes. One to indicate whether it's a compile-time reference (a <Reference>), and the other to indicate whether it's a run-time requirement. This provides enough information to intelligently resolve the tree of transitive dependencies when creating build output.

An example:
<package id="Library" version="" targetFramework="net403" referenced="true" />
<package id="Library2" version="1.0" />
<package id="Tool" version="0.5" referenced="false" runTime="false" />

eloekset wrote May 13, 2013 at 2:20 PM

Great! I can see that adamralph's pull request was accepted in the 2.4 release. However the docs still seem to miss the feature.

When looking at the pull request, it seems to be a IsDevelopmentDependency attribute on a Reference node. Is that correct? And could we please update the docs?

adamralph wrote May 13, 2013 at 3:07 PM

The version in that comment is out of date. The feature is now included in version 2.7.

murilorocha wrote Jul 16, 2013 at 11:30 PM

I tried the following and I had open few issues:

Attributes testing
              Valid inputs

Input:  <package id="xunit" version="1.9.1" />
Input:  <package id="xunit" version="1.9.1" developmentDependency="false" />Expected: xunit is included as dependency when Pack is used. It must be same with or without -IncludeReferencedProjects.

Input: <package id="xunit" version="1.9.1" developmentDependency="true" />
Expected: xunit is NOT included as dependency when Pack is used.

Invalid inputs

Input: <package id="xunit" version="1.9.1" developmentDependency="" />
Input: <package id="xunit" version="1.9.1" developmentDependency=true />
Input: <package id="xunit" version="1.9.1" developmentDependency=false />
Input: <package id="xunit" version="1.9.1" developmentDependency=invalidString />
Input: <package id="xunit" version="1.9.1" developmentDependency="invalidString" />
Expected: Error message.

Other inputs (see behavior)

Input: <package id="xunit" version="1.9.1" developmentDependency="1" />
Input: <package id="xunit" version="1.9.1" developmentDependency="0" />
Input: <package id="xunit" version="1.9.1" developmentDependency=1 />
Input: <package id="xunit" version="1.9.1" developmentDependency=0 />
Update scenario Action:
        • Create a C# Class Library project. 
        • Install an older version of package xunit (
        • Add attribute developmentDependency to this package in package.config.
        • Update xunit package to a newer version .
Expected: Attribute must be kept.
Reinstall scenario Action:
        • Create a C# Class Library project. 
        • Install xunit package.
        • Add attribute developmentDependency to this package in package.config.
        • Reinstall the package.
Expected: Attribute must be kept.
Uninstall scenario Action:
        • Create a C# Class Library project. 
        • Install xunit package.
        • Add attribute developmentDependency to this package in package.config.
        • Uninstall the package.
Expected: The package tag is removed.
Restore scenario Action:
        • Create a C# Class Library project. 
        • Install xunit package.
        • Enable package restore.
        • Delete packages folder.
        • Restore packages through interface.
Expected: Restore command is successful (no problems with the additional attribute).
Multiple packages Action:
scenario • Create a C# ASP.NET MVC 4 project.
        • Install the following packages: AutoMapper, Lucene.Net, nunit, recaptcha, xunit:
        • Set developmentDependency attribute for each installed package with the values:
                ○ AutoMapper - false
                ○ Lucene.Net - true
                ○ nunit - true
                ○ recaptcha - false
                ○ xunit - false
        • Create a package for the project.
        • All the previously installed packages are included as dependencies. 
        • AutoMapper, recaptcha, and xunit are included as dependencies. 
        • Lucene.Net, nunit are NOT included as dependencies. 
Regression testing - MirrorCommand.cs
        • It does not affect old code. It just adds additional parameter in the constructor call.
        • What does parameter isPackageConfig mean? There is a big conditional in which one of the branches was not changed.
        • No action needed.
- ProjectFactory.cs 
        • It affects old code.
        • "Where" method applied over the set of packages.config packages. Changes probably would have already been caught.
        • Action: Rerun tests.
- PackageReference.cs
        • It does not affect old code. It just adds a new attribute to the class.
        • No action needed.
- PackageReferenceFile.cs 
        • It does not affect old code. It just adds a new attribute to be parsed. 
        • New code is tested by different attribute values in the packages.config (parsing).
        • No action needed.
- NuGetResources.resx
        • It does not affect old code. It just adds error message.
        • New code is tested by invalid attribute values in the packages.config.
        • No action needed.
Compatibility Try with older version of NuGet and check backwards compatibility (NuGet 2.2):
        - Attributes testing (valid inputs)
        - Update scenario
        - Reinstall scenario
        - Uninstall scenario
        - Restore scenario
Documentation Action: Review documentation and find where it must be changed.

adamralph wrote Jul 17, 2013 at 6:05 AM

Was all the testing successful?

murilorocha wrote Jul 17, 2013 at 6:02 PM

Most of it. However, we detected two important issues:

Other minor issues were detected, but they are more related to the user experience:

Overall the quality is good.