Reputation: 1296
I have a library built using .netstandard framework and say the version of that library is 1.1.2. Now i have a .NET Core application built using that library(version:1.1.2).
If i upgrade the library version to 1.1.3, without recompiling is there a way to run the same .NET Core application against 1.1.3?
In .NET Framework we have bindingRedirect which can be set in the App.Config file and the .NET Framework application built using library version 1.1.2 can run against a library with version 1.1.3/1.1.1 as well without recompiling.Is there a similar thing for .NET Core as well?
Upvotes: 1
Views: 1398
Reputation: 29839
If i upgrade the library version to 1.1.3, without recompiling is there a way to run the same .NET Core application against 1.1.3?
Yes - just replace the dependency with the updated version and it should just work (assuming of course that the updated dependency hasn't changed its public API from version 1.1.2).
.NET Core behaves differently to Framework in that its runtime (CoreCLR) attempts to resolve dependencies by looking for versions that are the same or higher than the application was built against.
.NET Framework's CLR looks for the specific version of the dependency that the application was built against - forwards compatibility is one of the reasons why the binding redirect mechanism had to be added.
Core's (arguably more logical) approach means that it doesn't support the concept of binding redirects at all - because it doesn't need them.
In .NET Framework we have bindingRedirect which can be set in the App.Config file and the .NET Framework application built using library version 1.1.2 can run against a library with version 1.1.3/1.1.1 as well without recompiling.Is there a similar thing for .NET Core as well?
No - as stated above, binding redirects aren't supported in Core and the dependency resolution algorithm only consider versions of the same or newer.
I can't find any documentation as to why there is no built-in support for older versions, but I suspect it's got a lot to do with the fact that such a scenario is both unlikely, and that supporting it ends up effectively causing the type of DLL hell that .NET was supposed to avoid.
.NET Core provides the AssemblyLoadContext
class, which you can extend to provide your own implementation of an assembly-loading algorithm to handle your specific case. For example, you could write an AssemblyLoadContext
that uses binding redirect rules from an app.config
file to load your dependencies (whether you should do something like this is another story).
Upvotes: 5