14

Resolved

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

description

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.

comments

Iristyle wrote Feb 22, 2012 at 2: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 4: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 27, 2012 at 11:00 PM

This is a candidate for package authoring enhancements in 1.8.

adamralph wrote Jun 7, 2012 at 9:11 AM

Bump! Yes please...

jrummell wrote Jun 14, 2012 at 5: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 6: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 5:09 PM

Bump.

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 :)

Thanks,

Brock

adamralph wrote Oct 30, 2012 at 4: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 5:50 PM

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

howarddierking wrote Jan 14 at 4:21 PM

Good suggestion, but not something that we have bandwidth to implement at the moment, especially since there is a work around. We would be happy to take a pull request.

** Closed by howarddierking 01/14/2013 9:21AM

adamralph wrote Jan 14 at 9: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 at 12: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 at 1: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 at 6:27 PM

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

adamralph wrote Jan 19 at 2: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 at 2:49 PM

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

adamralph wrote Jan 19 at 5:16 PM

I've sent a pull request which solves this issue.

http://nuget.codeplex.com/SourceControl/network/forks/adamralph/nuget/contribution/3948

adamralph wrote Jan 20 at 9:46 AM

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

adamralph wrote Jan 22 at 9:35 PM

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

johncrim wrote Jan 24 at 5:41 AM

Enhancement to the current proposal detailed here:

http://nuget.codeplex.com/discussions/430179

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="1.2.2.0" targetFramework="net403" referenced="true" />
<package id="Library2" version="1.0" />
<package id="Tool" version="0.5" referenced="false" runTime="false" />

eloekset wrote May 13 at 1: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 at 2:07 PM

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

Sign in to add a comment or to set email notifications