3

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);
Luca
  • 11,646
  • 11
  • 70
  • 125

3 Answers3

4

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.

Community
  • 1
  • 1
MarcE
  • 3,586
  • 1
  • 23
  • 27
1

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.

RobV
  • 28,022
  • 11
  • 77
  • 119
  • 1
    A file reference won't see Debug/Release/x86/x64 compilations. But the Juozas Kontvainis's answer at http://stackoverflow.com/questions/915712/how-to-set-specific-version-property-for-project-references-in-visual-studio could solve the problem nicely in this direction. – Luca Aug 23 '11 at 10:10
  • @Luca Fair enough though the OP didn't ask about different compilations, useful info nonetheless – RobV Aug 23 '11 at 10:14
0

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.

Tigran
  • 61,654
  • 8
  • 86
  • 123
  • Yep, fixing version revision to 68 (instead of the default one *), plugins are loaded and running correctly even in the case of base library recompilation. So, how do I ignore revision on plugin loading? I'd like to mark binary changes only with major and minor versions. – Luca Aug 23 '11 at 09:29
  • Just leave it 0, what is a problem with that? – Tigran Aug 23 '11 at 09:32
  • Version revision identify the source/binary release. A revision change requires every plugin recompilation (and deployment also). – Luca Aug 23 '11 at 09:44
  • Ok, but again, leave as 0 and increment that fraction of version you need. I mean if you don't want to change last number, don't chnage it, noone and no any technology will force you to do that. – Tigran Aug 23 '11 at 09:49