sector 42

A little late to the party perhaps, but the entry of Microsoft into this arena is going to prove interesting.

From the linked talk, it looks like they are taking a lot of ideas from existing frameworks, and not getting much wrong.

Microsoft are definitely making their stack much more appealing.

• IIS7 looks extremely pluggable (lifting pages from Apache), you can insert managed code into myriad extension points.
• VS2008 has LINQ (courtesy of .NET framework 3.5) and associated entity design and modeling tools for clean data access layers.
• Now the MVC framework, which looks like a very clean implementation, supporting both static and dynamic languages (courtesy of the DLR as far as I understand).

I know I’m going to get flak from some of my more opinionated friends for saying this, but look at the developments from a technical point of view, leaving aside the usual frothing about lock-in, and proprietary software, etc etc.

I can’t help but think this has the possibility to significantly decrease the amount of existing .NET developers switching to frameworks like Django or Rails – Microsoft has typically been very good with tooling, and this looks like it will be no exception.

Prove me wrong?

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).