All geek questions in one place

Change dependencies depending on the type of target project

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

How can this be achieved, for example, using a powershell script? Or do I need to deploy two different packages in this case?

+4
source share
1 answer

Unfortunately, the current nuspec file does not provide dependency management based on the type of project. We currently support targeting different versions of the framework, but this is not applicable in your situation.

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

First determine if the link to the web package in a non-web project is really a problem. Just because links are referenced, if they are not used, this should not be affected.

If it turns out that having dependencies on the Internet causes unwanted side effects, you need to create separate packages.

I would break your package into logical parts. As you claim, you have a package that is used by non-web projects. Web projects require a dependency on another package.

So, now you have 2 logical packages:

  • Myproject
  • Myproject.web
    • MyProject (dependencies)
    • SomeOtherPackage

Thus, the user will Install-Package MyProject for non-web projects and Install-Package MyProject.Web for web projects.

At this point, you are done and everything will be all right. But I think you should consider one more step. One of the problems that I see with these split packages is that I need to figure out which package I need to install. I need to know that I need the Web version.

At this point, determine a typical use case for your package. If 90% of your users install the web version, then I would make a "meta" package that just has dependencies for your shared packages.

In your case, I would do 3 packages:

  • MyProject (meta package)
    • Myproject.web
  • Myproject.web
    • MyProject.Core
    • SomeOtherPackage
  • MyProject.Core (general non-web package)

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

A good example of this is the SignalR package.

Hope this was helpful.

+4
source

Source: https://habr.com/ru/post/1388623/

More articles:


All Articles