7

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, e.g. 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.

Bizhan
  • 16,157
  • 9
  • 63
  • 101
BurghardH
  • 73
  • 6
  • 2
    If I were you, I'll upgrade project1 dependency to match project2 version, and then use one dependency on both. This would take some effort and time, but it's one-time job, which will make things much smoother in the future. As maintaining different versions of the same dependency would be a pain in the neck in the future, and also, you might end-up upgrading them both to the latest version or worse, converting them to a different dependency !. – iSR5 Dec 06 '19 at 11:14
  • If you absolutely don't want to update your solution, AND the nuget package is an open sourced project with an MIT license, then I suggest you clone the repo from the old version and repack it with a different name. – Bizhan Dec 06 '19 at 11:26
  • The external library is developed by another project team and can't be influenced. So even in the future, there will be versions, which are not compatible to another and I have the constraints to use one exact version in a specific project. – BurghardH Dec 06 '19 at 11:36
  • @Bizhan This question relates to dotnet core because .NET Framework handles this problem in another way. – BurghardH Dec 06 '19 at 11:38
  • in Publish folder you will only have a higher version. – Mani Dec 06 '19 at 16:41

1 Answers1

0

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.

Jacek Blaszczynski
  • 3,183
  • 14
  • 25