Issue: https://nuget.codeplex.com/workitem/1956
Pull request: https://nuget.codeplex.com/SourceControl/network/forks/adamralph/nuget/contribution/3998
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":
```XML
<packages>
<package id="D" version="1.0" isDevelopmentDependency="true" />
</packages>
```
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:
```XML
<dependencies>
<dependency id="B" version="1.0" /> <!-- It has to be removed manually -->
<dependency id="C" version="1.0" />
</dependencies>
```
Expected:
- 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.
Comments: 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.
Pull request: https://nuget.codeplex.com/SourceControl/network/forks/adamralph/nuget/contribution/3998
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":
```XML
<packages>
<package id="D" version="1.0" isDevelopmentDependency="true" />
</packages>
```
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:
```XML
<dependencies>
<dependency id="B" version="1.0" /> <!-- It has to be removed manually -->
<dependency id="C" version="1.0" />
</dependencies>
```
Expected:
- 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.
Comments: 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.