.Net Add-ins and versioning

Question

Our media center add-in is shipped as a single DLL which lives in the GAC (mediabrowser.dll), we allow users to write extensions for our add-in by referencing our DLL and accessing the pre-defined extensibility points.

On load we search through a plug-in directory, load all the assemblies in the directory, search the assemblies for a type implementing IPlugin and execute initialiaztion routine on an instance of the plugin. I am aware that this is not the most robust design (for example: we may want to look at appdomain isolation for plugin later on) but it works alright now.

As it stands, this seems to be working fine, except for one big caveat.

When plugin writers compile their plugins the plugin references mediabrowser.dll with a specific version. Later on when we revise our dll (to fix bugs or add features) all addins that were written against earlier versions of mediabrowser.dll break.

I have thought of a few solutions to this problem (note the assembly is in the GAC):

1. Ship a publisher policy with with mediabrowser.dll that will redirect all earlier compatible versions of mediabrowser.dll to the current version (this must also live in the GAC).
2. Ship a separate assembly which contains all the fixed extension points and contracts, be extra prudent about changing this assembly, have plugin writers link against this assembly. (but still look at using publisher policies for non-breaking changes to the interfaces)
3. Let a third party worry about this stuff and leverage MEF or some other framework that takes care of this kind of stuff.
4. Hookup AppDomain.CurrentDomain.AssemblyResolve and resolve the earlier versions of the assembly to the current version. This will only work if the assembly of that specific version is not in the GAC.

Are there any other solutions to this problem that I am missing?

Update I ended up going with option 4.

Answer 1

I see you have picked an answer but if you are still open to ideas there is another option to consider (the very one used by the .NET framework): do not increment your assembly version between builds (but do increment your assembly build number).

This will allow your assembly to retain it's same strong name, not breaking plugin compat, and still allow you to distinguish builds from each other (using the assembly build number).

You can see this in action in .NET 2.0 through 3.5. Those releases all use the assembly version 2.0.50727 but have distinct build versions.

As long as you do not break your interface contracts (which you should never do anyway) this approach is quite reasonable.