Using versions of .Net assemblies
In our software, we are moving from one version of the external assembly to a newer version. Although the overall task of the assembly is the same, the API is radically different and is not backward compatible. The API is responsible for fetching data from external stations, which can work with the corresponding new or old API (also without backward compatibility). We have no control over the software externally or externally. The external assembly is not strongly signed, and the module in the assembly has the same name for both versions.
Instead of maintaining two versions of our processing software, we would like to dynamically develop it and use either an old version or a new version of an external assembly that depends on an external station for communication. We can determine if the external station supports the new version, so the choice of "version" can be more or less explicit.
So, we have an external assembly ComLib.dll in two versions. Can we reference two versions from the same assembly / project and how can we distinguish between the two assemblies when defining types, etc.?
Assuming the above cannot be done from a single assembly / project, we could implement specific "adapters" for specific versions, one for each version of the external assembly (I think we already have sufficient interfaces and abstractions for this). but are there any caveats we should be looking for or some specific setting to avoid runtime type / version confusion (assembly permission / load, etc.)? Is there sufficient side-by-side support in the .NET runtime for this setup?
UPDATE: Added another twist to this question to make things more interesting. The external assembly seems to load additional assemblies and use external config files. Since different versions require different config files and different additional assemblies, each version must somehow load additional assemblies that match their version.
It seems to me that we want the assemblies from each version to be loaded using "root" in a separate folder containing their configuration file and additional assemblies. Is this possible with the standard build collector / loader, or will we need to do some magic and maybe load the assemblies manually (in separate AppDomains?) To force the use of "root" folders?
source to share
A good post on options for this can be found here: http://kevin-berridge.blogspot.com/2008/01/two-versions-of-same-shared-assembly.html
source to share
You can sign assemblies yourself using ILMerge and then use this method to reference them from the same project.
source to share
You say that this code is used to communicate with outside stations. Why not make a service out of code that interacts with external stations? This service will be called from your current program.
This will allow you to have two versions of the service, one for the old API and one for the new one. Each service will have its own process (or perhaps AppDomain) in it, so it can load versions of assemblies that it likes. In the process of moving your main program from one station to another, you switch from one service to another with a change in the API version.
This will have the added benefit of isolating you from your external provider by creating a third version of the API that is not backward compatible with the first two.
The performance of this solution can be quite high as your main program can communicate with services over named pipes or even with an in-memory transport. WCF can switch between transports (bindings), in most cases without changing your code.
source to share