vladek
vladek

Reputation: 617

How does .NET 6 deal with assembly reference conflicts?

Let's say I got projects A, B and C. Project A references projects B (v. 2.0.0.0) and C (v. 3.0.0.0). Project B references only project C (v. 1.0.0.0). We got a conflict on our hands, since project A and B depend on different assembly versions of project C. In .NET framework we solve this issue using binding redirects. In Project A's app.config file (being the main project) we add:

<dependentAssembly>
    <assemblyIdentity name="C"  
                      publicKeyToken="<somePublicKeyToken>"  
                      culture="en-us" />  

    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />  
</dependentAssembly>

I believe that binding redirects are no longer a thing in .NET Core and .NET 5 forward. Instead of referencing an assembly, we reference a NuGet package or a project. My question is: how is this issue solved in newer version of .NET? Why were binding redirects a thing in the first place? Hope my question makes sense.

Upvotes: 6

Views: 4752

Answers (1)

Elroy Flynn
Elroy Flynn

Reputation: 3218

As others pointed out, a package version is a completely different thing from an assembly version. In the end, your build still refers to an assembly. It just happens that the assembly was delivered to your build environment in a package.

You are correct that .Net 5+ does not (by default) require that the assembly version used at runtime match the assembly version used at build time.

I'll speculate that the early design of .Net was attempting to address the "DLL Hell" problem. By formalizing the notion of the DLL version (by placing the version in the metadata of the assembly), an application could verify that it was getting exactly the version that it expected to get, and so would have dependable behavior. Still, you wanted to be able to use a newer version at times, without rebuilding the referring application, so <bindingRedirect was provided.

.Net Core recognizes that it wasn't a successful design. The new approach a) ignores strong naming: it doesn't affect behavior. b) defaults to allowing any version at runtime, and c) provides a new mechanism for enforcing version policy: AssemblyLoadContext

Upvotes: 4

Related Questions