Using versioned .Net assemblies

Question

In our processing software we are moving from one version of an external assembly to a newer version. While the overall task that the assembly performs are the same, the API is radically different and no backwards compatibility have been maintained. The API is responsible for extracting data from external stations which may be running with a matching new or the old API(also no backwards compatibility). We have no control of the software in the external assembly or on the external stations. The external assembly is not strongly signed and the module in the assembly have the same name for both versions.

Instead of maintaining two versions of our processing software we would like to evolve it dynamically and have it use either the old version or the new version of the external assembly dependent upon the external station to contact. We are able to determine if an external station supports the new version, so the choice of "version" can be more or less explicit.

So the setup is we have an external assembly ComLib.dll in two versions. Can we reference the two versions from the same assembly/project and how can we distinguish between the two assemblies when determining types etc?

Assuming that the above cannot be done from within a single assembly/project, we could implement version specific "adapter" assemblies, one for each version of the external assembly (I think we already have sufficient interfaces and abstractions in place for this) but are there caveats we should be looking out for or some specific settings to avoid type/version confusion at runtime (assembly resolving/loading etc.)? Are there sufficient "side-by-side" support in the .NET runtime for this setup?

UPDATE: A further twist to this question is added just to make things more interesting. Seems that the external assembly loads additional assemblies and uses external config files. Since the different versions needs different config files and different additional assemblies each version needs to somehow load the additional assemblies that match their version as well.

Seems to me that what we want is the assemblies from each version to be load with a "root" in a seperate folder that contains their config file and additional assemblies. Is this even possible with the standard assembly resolver/loader or would we have to do some magic and perhaps load assemblies manually (in seperate AppDomains?) to enforce "root" folders?

Answer 1

Hi, A good post about the options for this can be found here: http://kevin-berridge.blogspot.com/2008/01/two-versions-of-same-shared-assembly.html

Answer 2

You could sign the assemblies yourself using ILMerge and then use this technique to reference them from the same project.

HTH, Kent

Answer 3

You say that this code is used to communicate with external stations. Why not make a service out of the code that communicates with the external stations? That service would be called from your current program.

This would allow you to have two versions of the service running - one for the old API and one for the new. Each service would be in it's own process (or maybe AppDomain), so could load the versions of the assemblies that it likes. In the process of your main program switching from one station to another, you would switch from one service to another as the API version changes.

This would have the additional benefit of isolating you from your external vendor creating a third version of the API that is not backwards compatible with the first two.

The performance of this solution could be quite high, as your main program could communicate with the services over named pipes, or even an in-memory transport. WCF can switch between transports (bindings), in most cases with no change to your code.