This project is read-only.

Development dependency feature does not allow to exclude solution dependencies


Pull request:

The current implementation for excluding development-time dependencies solves most cases and it is useful, however, it does not solve completely the problem. It does not allow to exclude dependencies on other packages of the same solution.

Suppose we have the following situation (see dependencies_example.png):
  • A given solution contains three projects, "A", "B", and "C".
  • "B" and "C" have nuspec files.
  • "A" is dependent on an external package "D".
  • "A" contains runtime dependency on package "C".
  • "A" contains dependencies on packages "B" and "D", but not runtime dependencies, i.e., we don't want to list them in the nuspec file.
If you want to create a package for "A", there is no way to exclude "B" from the dependencies because it does not appear in packages.config, only "D":
    <package id="D" version="1.0" isDevelopmentDependency="true" />
If you run:
    NuGet Pack -IncludeReferencedProjects
NuGet will look at the csproj file, it will find a reference to project "B" and then It will include it as a dependency as follows:
    <dependency id="B" version="1.0" /> <!-- It has to be removed manually -->
    <dependency id="C" version="1.0" />
  • It allows to remove project dependencies in the csproj file.
  • Or it allows to remove project dependencies in the packages.config.
  • Or it uses a separate file to exclude dependencies.

file attachments


adamralph wrote Aug 2, 2013 at 6:11 PM

I'm not convinced that an additional feature is required here. The -IncludeReferencedProjects switch is a convenient way of including project references without putting them in the nuspec. If I only want certain project references to be included then I should just put them in the nuspec and not use that switch, no?

Chance wrote Sep 7, 2013 at 4:00 PM

I disagree for two main reasons:
  1. Consistency - why should project references be handled any different from external dependencies? If anything having a project reference should always allow you to do more, not less.
  2. Convenience - you mentioned that the -IncludeReferencedProjects is a convenience, and you're absolutely right! In fact, it's so convenient that I almost wish I wouldn't have to use .nuspec at all for handling dependencies. Why declare the dependency tree twice? Unnecessary redundancy is just asking for errors.
My two cents.

adamralph wrote Sep 14, 2013 at 3:53 PM

If project A has a reference to project B, how can it be a development dependency only? A reference would seem to imply a runtime dependency.

Can you give an example?