sector 42

I had an interesting assembly usage requirement today.

(For my Java friends, assembly is analogous to JAR file).

We have an existing gateway application (could I be any more vague?) that receives relatively high amounts of message traffic. We’re in the progress up preparing to go live with a new version of the application for updated security requirements.

We also have a number of gateway users who are not quite ready to switch over to the updated version of the service (as usual), despite the long lead times they have been given to prepare.

Here’s the issue – The gateway application uses a particular version of an assembly (let’s call it A1) to connect to a backend system. This system needs to be connected to by customers who have not yet switched over. The new version of the gateway uses assembly version A2 to connect to the updated backend software.

It just so happens that both assembly A1 and A2 use the same base namespace, and by and large, the same class and type names, but with small incompatibilities.

It also happens that the loading of these assemblies will happen inside the same AppDomain. Hmm.

In this case, .NET reference aliases do what we want.

1. Add references to both A1 and A2 in your project. If they both have the same filename, either rename one, or put one in a different directory (I hope its obvious why).
2. On the reference properties pane, change the alias from global to something suitable, e.g. A1Ref and A2Ref.

In your code, declare the alias, and bring in the namespace by qualifying it:

extern alias A1Ref;
extern alias A2Ref;
using A1NS = A1Ref::Common.Namespace.Name;
using A2NS = A2Ref::Common.Namespace.Name;

Now you can use A1NS or A2NS like regular namespaces, depending on which assembly types you want to use.

You have to admit this is pretty cool. In Java I would probably have had to write a custom ClassLoader (correct me if this is no longer correct, it’s been a while).