Question

I have a package Ninject.Extensisons.Wcf which shall be installed differently depending on the type of the project to which it is installed. In the case where WCF is hosted in IIS (any project containing global.asax) a second package Ninject.Web.Common needs to be installed together with the package. For all other project types such as libraries, Console, WinForms, WPF applications this package should not be installed.

Is it somehow possible to achieve this e.g., using a powershell script? Or do I have to deploy two different packages in this case?

Answer 1

Unfortunately the current nuspec file does not provide for managing dependencies based on project type. We currently support targeting different framework versions, but that doesn’t apply in your situation.

It is recommended that all dependencies are handled using package references. Although it would be technically possible to download and install a package using a PowerShell script, this is not supported and will most likely break in future versions.

First determine if it would actually be a problem to reference a web package in a non-web project. Just because assemblies are referenced, if they are not used, it should not have an impact.

If it turns out that having the web dependency causes undesirable side-effects, then you’ll need to create separate packages.

I would split up your package into logical pieces. As you state, you have a package that is used by non-web projects. Web projects require a dependency on a different package.

So now you have 2 logical packages:

• MyProject
• MyProject.Web
  • MyProject (dependencies)
  • SomeOtherPackage

So a user would Install-Package MyProject for non-web projects, and Install-Package MyProject.Web for web projects.

At this point you would be done and everything would be fine. But I think you should consider another step. One of the issues I see with these split packages is that I have to figure out which particular package I need to install. I have to know that I need the “Web” version.

At this point, determine the typical use case for your package. If 90% of your users will be installing the Web version, then I would make a “meta” package that simply has dependencies for your common packages.

In your case I would make 3 packages:

• MyProject (meta package)
  • MyProject.Web
• MyProject.Web
  • MyProject.Core
  • SomeOtherPackage
• MyProject.Core (common non-web package)

By creating the “meta” package, you can reserve the “short” package name for the most common case. This meta package only has dependencies to other packages.

A good example of this is the SignalR package.

Hope this was helpful.