如何解决dotnet核心中的nuget依赖地狱？

Question

I am developing on an asp.net core solution with a handful of different projects and each project uses a 3rd party NuGet package of a certain versioned library. These versions, eg 1.0.0 and 2.0.0, have breaking changes. Additionally, this library is developed by another project team and it can't be influenced by me. So in the future, there will be versions which are not compatible to another and my constraints are to use one exact version in a specific project.

The following is a minimal overview of the solution:

• MySolution
  • WebApp
  • Project1
    • CustomLibrary (v1.0.0)
  • Project2
    • CustomLibrary (v2.0.0)

During development in Visual Studio, everything is fine and I can use the individual methods of my versioned library in each project. If I finally publish my application, there is only one CustomLibrary.dll with v2.0.0 in the output folder.

I am a little bit confused about that. Does this dll hold both versions and dotnet can resolve them during runtime? If this is not the case, the application will fail during runtime because the methods and output of v1.0.0 can be entirely different from v2.0.0.

(In .Net framework I could do this , but it seems it doesn't apply in .Net Core)

Is there a solution to deploying different versions of the same strong-named library? I would imagine that it should be possible to deploy specific versions of NuGet packages?

I'd really appreciate it if you could help me out.

Answer 1

There are a couple of .NET Core architectural limitations which will impact application design:

1. One cannot load into single .NET Core process different versions of the same assembly at the same time. This limitation will prevent your app from using both projects at the same time.
2. There is no publishing process that would magically combine two versions of the assembly into one universal assembly.

Keeping this in mind you would need to redesign your app and load Project1 with CustomLibrary v1.0.0 dynamically during the runtime. The same goes for the Project2. You should end up with a new architecture where Project1 and Project2 would be published into different file system locations and loaded dynamically during runtime.

In the case, your application needs to work with both Project1 and Project2 during its lifespan it would be possible providing your assembly would play nicely with collectible AssemblyLoadContext. The scenario would be that both Project1 and Project2 would be capable to be loaded and unloaded with collectible AssemblyLoadContext and application would switch between them on demand.

Hope this will help in solving the problem.