How should I handle strong name issues associated with plugin type systems in .Net

Question

I am working on an SDK. The goal of the SDK is to unify access to various hardware products. As such we have settled on a plugin architecture, using an abstract factory pattern for creation. The issue I have is that anytime the SDK changes I have to have the project teams recompile their plugins. Obviously this is necessary if the interfaces they are relying on, or implementing have changed. My issue is when I fix several bugs (but change no interfaces) they still need to recompile because the plugins are attempting to load a specific version of the SDK (based on the assemblies strong name). My options as I understand them are:

1. Don't strongly name my SDK assemblies. This is not acceptable ultimately as many of our customers require that .Net assemblies be strongly named.
2. Create a Publisher Policy. I suspect I will use this eventually, but I am not happy with the idea that two application installed on the same machine cannot use different versions of the SDK.

I understand that what I am looking for would get me DLL hell again, but in this case I feel I need that. Is there something I am missing?

Pat O

Answer 1

Is the SDK being placed in the GAC? If not then http://msdn.microsoft.com/en-us/library/0a7zy9z5(vs.71).aspx might be helpful. I seem to recall seeing an easier way to do this through configuration but can't recall where or how to do this and haven't been able to find any details.

Another possibility is to use assemblyBinding in the app config. It looks like this would allow you to indicate that when version 1.0 is requested to load version 2.0 instead. This still places the effort on the adapter creators, however it should only require them to drop some canned xml into the app.config. http://msdn.microsoft.com/en-us/library/twy1dw1e.aspx

From that link the config would have something like this:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly"
                              publicKeyToken="32ab4ba45e0a69a1"
                              culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0"
                             newVersion="2.0.0.0"/>
            <codeBase version="2.0.0.0"
                      href="http://www.litwareinc.com/myAssembly.dll"/&gt;
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Likely the best option going forward is to pull out the public interfaces into a separate assembly for the adapter authors to use. This would allow the interfaces to be versioned independent of the implementation.

Answer 2

We have chosen to use the Publisher Policy file. The methods above require intervention on the part of the adapter writer. Our goal was to use and adapter with a new (patched) version of the SDK. The down side of the Publisher Policy file is that it effects all applicaiton that are running on the machine.

Still it works.

Pat O