CODEWITHSUNDEEP
c#
helion3
helion3

Reputation: 37481

Controlling DLL version compatibility for more flexibility

I have two C# DLLs - an "api" dll, a collection of interfaces for an application, and a "plugin" dll, code that uses the API to extend our application.

Whenever I make a new "api" build, the plugin dll fails to load in our application:

The classes in the module cannot be loaded.

To fix this, we simply have to rebuild the plugin (since it's using the "latest" API dll.

My guess is it has to do with how Visual Studio or the compiler is versioning the DLLs. Right now the API dll is versioned as 1.0.6469.2848 which is automated.

I need a bit more flexibility but I don't know how to go about it. I'm choosing the wrong terminology when looking for solutions.

Preferably, I'd like something closer to semver - my plugin DLL should continue to load/work if it was compiled against api version 1.0.1, even if my application has api version 1.0.2, or 1.1. Only 2.x, "backwards-compatibility breaking API changes" should be rejected.

Upvotes: 1

Views: 834

Answers (2)

Bronumski
Bronumski

Reputation: 14272

As I think yo have found out, it is the assembly version that is messing you up. This is because the plugin's version build/macro number has incremented and the application was built against a previous version.

You could deal with this in a couple of ways.

  • In the application config you can do a binding redirect so that it loads up the newer version.
<dependentAssembly>
  <assemblyIdentity name="someAssembly"
     publicKeyToken="32ab4ba45e0a69a1" culture="en-us" />  
  <bindingRedirect oldVersion="1.0.0.0-7.0.0.0" newVersion="8.0.0.0" />  
</dependentAssembly>
  • Alternatively and probably the route I would take and sticking to semver I would manually control the AssemblyVersionAttribute (1.2.3) only incrementing on breaking changes. The AssemblyFileVersionAttribute I would increment with the build so that you can determine the actual build version of a dll. You can change this in the AssemblyInfo.cs

I did answer another question on assembly versioning that might help.

Note

Depending on how you are building your assemblies (locally or on a build server) how you generate the version number will differ. If you are building locally you will need to, as Sylence pointed out in his answer, change the wild card in the AssemblyVersionAtribute. If you are using a build server such as TeamCity, Jenkins, et al. then you can completely overwrite the assembly and file versions prior to the compile.

Upvotes: 2

Sylence
Sylence

Reputation: 3073

Look for an AssemblyInfo.cs file in your API project. There you have an AssemblyVersion and AssemblyFileVersion that you can set to whatever you want. Just make sure you don't use a * in the version. This way the version will keep the same after each build.

Upvotes: 1

Related Questions