C# plugin system binary compatibility issues

Question

I've implemented a plugin system in .NET. The base library implements basic classes and interfaces exposed to plugins, the plugin libraries links the base library for using exposed classes and interfaces.

The problem I'm facing is that a (simple) recompilation of the base library (with or without modifications) cause the plugins not able to being loaded, giving the exception message:

 "Could not load file or assembly 'BaseLibrary, Version=0.0.1.68, Culture=neutral, PublicKeyToken=7b445b12e635292c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

This problem is solved by compiling all at once the base library and the plugin libraries, but this is not very comfortable during development, since I modify base library quite frequently in this phase.

If there any method to "relax" binary matching?

Is it possible that the base library assembly information (quoted below) could be the casue of the problem?

 [assembly: AssemblyVersion("0.0.1.*")]

I forgot to mention that assemblies are signed.

---

Assemblies are loaded using the following routine

Assembly hLibrary = Assembly.LoadFile(pPath);
Type plugImageCodecFactoryType = hLibrary.GetType("Derm.ImageCodecPluginFactory", true, false);
object plugImageCodecFactory = Activator.CreateInstance(plugImageCodecFactoryType);
object plugInstance;

MethodInfo plugFactoryCreate = plugImageCodecFactoryType.GetMethod("CreatePlugin", BindingFlags.Instance|BindingFlags.Public);

plugInstance = plugFactoryCreate.Invoke(plugImageCodecFactory, null);

if (plugInstance is IImageCodecPlugin)
    RegisterPlugin((IImageCodecPlugin)plugInstance);

Answer 1

Read these questions and answers for a more thorough discussion on the use of AssemblyVersion vs AssemblyFileVersion.

Ignoring build numbers when referencing DLLs

Differences between AssemblyVersion and AssemblyFileVersion

The short version is that you should only change AssemblyVersion when you introduce a potentially breaking change on that assembly that will force dependants to take a new version.

For minor changes you can use AssemblyFileVersion to mark differences.

So I would use a static assembly version for development, increment it when you get to a stable release that you want to manage going forward and manage future version increments manually.

Answer 2

Assuming you are using Visual Studio look at the references in one of the projects that is a plugin. When you look at the properties for the reference to your base library what is the SpecificVersion flag set to? Try setting it to False and see if that makes a difference.

Note that if your project is using a project reference rather than a direct reference to the compiled DLL this flag won't be present. In this case you either need to use a fixed revision number on the base library like you've tried or you should switch to using a direct reference to the DLL instead so you can alter the SpecificVersion property.

Answer 3

To me here is nothing related to plugins as compiler error talks about base library, and considering that you implemented plugin base architecture, plugins have to be completely decopled and loaded lazy. So even if there is a plugin loading problem, you will meet at runtime and not compile time.

So for me the cause is your assembly version.

Regards.