1

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.

helion3
  • 34,737
  • 15
  • 57
  • 100

2 Answers2

2

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.

Community
  • 1
  • 1
Bronumski
  • 14,009
  • 6
  • 49
  • 77
  • So is `AssemblyVersion` the value which affects whether other DLLs are "loadable", or is that the `AssemblyFileVersion`? In addition to manually controlling the version I need to make sure that plugins compiled against API version 1.0.0 will still work when using API version 1.0.1. I'd like to stick with semver so only 2.x would include breaking changes, so v 1.0.1 or 1.1 should be safe for mods compiled against v1.x – helion3 Sep 19 '17 at 17:20
  • @helion3 Yes it is the AssemblyVersion. The file version is just informational. You will have an issue if you compile against 1.0 and then try to use 1.1. That is where the binding redirect would help. However, if you have a known interface or base class that you code to you can consider loading assemblies at runtime in the same or separate app domain. You could also check out MEF, although I think that has been replaced by another Framework for net.core. – Bronumski Sep 20 '17 at 19:44
1

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.

Sylence
  • 2,975
  • 2
  • 24
  • 31