CODEWITHSUNDEEP
c#.net-corenuget
Anthon Nilsson
Anthon Nilsson

Reputation: 123

Force nuget sub nuget version

Is it possible to access the same nuget package but different versions of it in the same netcore project?

I have a net core api that logs to elasticsearch. It uses the package: Serilog.Sinks.Elasticsearch - 6.5.0, which has Elasticsearch.Net - 6.0.0 as its own reference.

Everything works fine and has done so for months. But now when I for another functionality added Elasticsearch.Net - 7.0.0-alpha2 manually to the project the subnuget for Serilog.Sinks.Elasticsearch is also upgraded, which breaks the functionality.

The new code based on Elasticsearch.Net - 7.0.0-alpha2 works fine though.

Is there any way to force the nuget reference for Serilog.Sinks.Elasticsearch so it uses Elasticsearch.Net - 6.0.0 while my own new code uses Elasticsearch.Net - 7.0.0-alpha2?

Nugets before new code:

enter image description here

Nugets with new code:

enter image description here

Upvotes: 0

Views: 408

Answers (2)

ganchito55
ganchito55

Reputation: 3607

The problem that you are having is known as "Dll Hell", there are many approach to manage it, for example:

  • Try to use strong name libraries and install them into the Global Assembly Cache
  • Apply an abstraction layer between dependencies
  • Encapsulate the use into different context

Maybe this old post can also help you.

Upvotes: 0

zivkan
zivkan

Reputation: 14981

Mostly no, but a little bit yes. It depends :)

The build system (NuGet, the .NET SDK, msbuild) creates build output with all the dlls in one directory. If you need elasticsearch.dll from two different versions of the package, how could this work? Obviously you can't have two files with a single name, so at least one would need to be renamed, but then when the CLR needs to load elasticsearch.dll, how would it know that it has a different name, and how would it know what the new name is?

So, using the built-in functionality in the build system it's not possible.

However, the .NET Framework does support loading different versions of a dll, you just need to do work in copying files and to tell it where the different versions are. Using the codebase element in an app.config file, you can tell it where the dlls are. You can see an example of this in use in %userprofile%\AppData\Local\Microsoft\VisualStudio\{your vs version folder}\devenv.exe.config. The vast majority of this file is binding redirects and codeBase elements. You'll need more advanced build scripts that just running dotnet publish to get all your dlls in the desired locations. It will probably prevent you from being able to start a debug session from VS, but you can always attach VS as a debugger to a running process, so it's still possible to debug, it's just harder.

This might be .NET Framework only. If it doesn't work on .NET Core, you can look into AssemblyLoadContext, but I've never seen a complete example, other than a no-op implementation that just uses the default context, but I think that might prevent loading multiple versions at the same time.

Another example of loading multiple versions of an assembly in the same process on the .NET Framework is using App Domains. But that's definitely .NET Framework only, in case you need to support .NET Core or the future One.NET (.NET 5). AssemblyLoadContext is the closest thing to app domains in .NET Core, but isn't the same thing.

To the best of my knowledge, Mono doesn't support loading multiple versions of an assembly at the same time, but my guess is that this will change once .NET 5 is released. But it's a guess that lacks any evidence or inside knowledge whatsoever.

Upvotes: 1

Related Questions