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?
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