Add NuGet package without its dependencies

Question

I am sure many of us have run into this issue and somehow i am having problems getting resolution anywhere.

I have a shared library (Common.Infrastructure.dll) across many projects and I am using TeamCity built in NuGet Server to host this library. This library internally relies on NuGet packages such as Fluent Nhibernate, Log4net, StructureMap, etc).

Quite simply, doing a "Install-Package Common.Infrastructure" in a project that needs this shared dependency also adds Fluent NHibernate, log4net, SM and so on) as "references" to the project. I am not going to use these dependencies of Common.Infrastructure directly, but would obviously need them in the output (bin/debug) folder eventually.

Is there a way to not have these dependencies referenced with built in nuget (nuspec) support?

Answer 1

The Install-Package command has a flag to ignore the dependencies. Example:

Install-Package Common.Infrastructure -IgnoreDependencies 

Answer 2

Please note, his actual question is about how to create a package that doesn't add dependencies, not how to install a package without its dependencies.

Using Nuspec you can explicit control which packages are dependencies and which assemblies in your package are referenced by the target project. However, I don't think there is a way to do exactly what you are asking with NuGet because there is no way to indicate to Visual Studio that an assembly should be copied to the bin directory without adding it as a project reference.

I think your problem is rather a symptom of lumping too much functionality into a single assembly. I recommend you split your Common.Infrastructure.dll into separate assemblies for the various aspects of functionality. Something like:

• Common.Infrastructure.Logging.dll - depends on Log4net
• Common.Infrastructure.Database.dll - depends on Fluent Nhibernate
• Common.Infrastructure.IoC.dll - depends on StructureMap
• Whatever other sub assemblies are appropriate
• Common.Infrastructure.dll - a new smaller core of functionality that depends only on the framework

Of course, the exact set of assemblies you break it down into will depend on what functionality is in Common.Infrastructure.dll and how you use it. Once you have separate packages for each of these assemblies, then you can choose which ones to reference in a given project and limit it to the aspects and dependencies that you really need.