Previous month:
January 2004
Next month:
March 2004

February 2004

Whidbey GAC & 64 bit

With Whidbey the directory structure of the global assembly cache changed. Using the Alpha version of Whidbey I cannot see the shared assemblies by opening the explorer to look at <windir>\assembly (using Windows XP). Of course it is possible to use the .NET 2.0 Framework Configuration utility to display these assemblies.

The reason for this is that the directory structure changed. The 1.0/1.1 shared assemblies are in the directory <windir>\assembly\GAC. The .NET 2.0 command line utility gacutil installs the shared assemblies into the directory <windir>\assembly\GAC_Neutral. Besides the directory GAC_Neutral there is a directory GAC_32 that keeps custom marshaler and Microsoft.VisualC assemblies.

I think the reason for this is the 64 bit version of .NET. Specific 64-bit assemblies (marshaling) will be in the GAC_64 directory, and the GAC_Neutral directory is for assemblies that are the same for both 32 and 64 bit versions.

This is a great feature of .NET: moving to 64 bit no changes are needed!
I remember a lot of hard work moving 16-bit applications to 32 bit!

Update: with the March Community Preview the directory GAC_Neutral changed to GAC_MSIL.


Properties and Fields

Martin Fowler blogs about that he liked the notion of properties from the beginning (compared to Java's getX/setX).

However, he doesn't like that fields and properties are handled differently by reflection, so it is not possible to change a field to a property afterwards. Now he has to write "stupid accessor functions for accessible data values".

I think this is just an issue on how much work it is to write properties. Using Whidbey, this is a fast & simple task. For VS.NET 2003 Frans Bouma has written a Macro to create properties.