GAC Structure

Everyone knows now that GAC physically have directories for each version of assembly. Now what happens when Whidbey Beta 1 is released as it supports both 32 bit platform and 64 bit platform. So if we have directory for each assemblies, there can be problem because both assemblies for 32 bit and 64 bit will have same assemblies unless Microsoft make them with different versions. This obviously is not the right way. We make an application on 32 bit platform using some assembly and then when we want to port it to 64 bit platform; we need to use assemblies with different version. Its not an easy and friendly way.

Before Whidbey, we had only one directory “GAC” which further had directories named after assemblies and they further had directories with respect to version. It was something like this “WinDir”\assembly\GAC\“AssemblyName”\ “VersionNumber”__“PublicKeyToken”. So what Microsoft has done is they have reorganised the directory structure a bit. They have new directories named “GAC_32” for 32 bit and something similar for 64 bit in future like “GAC_64”. This structure can be viewed by disabling the Cache Viewer. To do this, go to registry editor, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion and change value for "DisableCacheViewer" to 1. If its not present, then create a DWORD value for it and set its value to 1. Now open explorer and see "WinDir"\assembly folder. You'll be able to see the physical structure of GAC.

Now after we install framework 2.0 Beta 1, we have 3 GACs in all. One is for “specific to 32 bit system” which is “GAC_32”, one for portal assemblies “GAC_MSIL” and the last one is for v1.0 and v1.1 called “GAC”.

Also, when we see the assembly folder in explorer, we see another column which tells us about the process architecture. It shows “MSIL” or “x86” or nothing. MSIL is for Portable Assemblies, x86 ones are 32 bit platform specific and the ones which don’t have anything are v1.0 or v.1.1 assemblies.

Note: The above implementation is for Framework 2.0 Beta 1. It might change in future releases.

.NET Memory Management and GC Myths

Just came across this series of post by Paul Wilson on .NET Memory Management and GC Myths. He talks about how to handle large objects and how .NET Framework internally manages memory when Object.Dispose() is called. Beside the post, the comments section is also good where they had good discussion on some points.

• .NET Memory Management and Garbage Collection
• .NET GC Myth #1 - Set Object to Null
• .NET GC Myth #2 - The GC Frees Memory
• .NET GC Best Practice - ALWAYS Call Dispose
• .NET GC is Excellent - Better Than Java