Microsoftie Junfeng Zhang has a peculiar post on retrieving the version number of the currently executing assembly from within the assembly itself. This is obviously useful for the sort of auto updating applications that I discussed in my recent CF webcast.

He lists the obvious approach which is to use the metadata reflection capability in .NET like thus:
Assembly.GetExecutingAssembly().GetName().Version

But Junfeng (a dev on the Fusion team) says:

“Of course, this works. But personally, I think it sucks that you need API to get properties of yourself.“

He instead suggests:
a) Creating an internal class with constant (and presumably static) members to hold 'all the interesting assembly properties' or;
b) Take the more sophisticated option of holding an external file with these properties in it and auto generating this Assembly Properties class along with the AssemblyInfo class at compile time.

Now to me this is just plain wrong. The 'important information' that is being talked about is classic metadata- it is information that describes the code. The very reason that we have the sort of metadata reflection techniques that exist in modern managed runtime environments such as Java is so that we don't have to hard code these sorts of properties that are not intrinsic to the logic of the code itself.

Versioning (as we are talking about here) is really a compiled code concept not a source code concept. Taking the approach suggested muddies this distinction. .NET versions at the assembly level and importantly a versioned assembly need not even contain any executable IL code- it may just be a resource containing assembly. What do we do then? Have one version discovery approach for code containing assemblies and one for resource containing assemblies? Have all of our resource containing assemblies include the special Important Properties class?

I find it very peculiar that someone who must be deeply involved with the .NET metadata mechanisms (for those that don't know Fusion is the managed/unmanaged stuff that locates and loads .NET assemblies) dismisses the usefulness in this case with a simple 'I think it sucks'... Is there something we don't know about here? Is this sort of reflection overly resource intensive? If not I don't really see why the the standard approach should not be favored.