Welcome to MSDN Blogs Sign in | Join | Help

GAC, Assembly ProcessorArchitecture, and Probing

As I mentioned in a previous post, assemblies in .Net framework 2.0 now have ProcessorArchitecture now.

64 bit .Net framework 2.0 redist will install both 64 bit runtime and 32 bit runtime. But there is only one GAC. And both 64 bit runtime and 32 bit runtime will share the same GAC.

We have to extend GAC to support assemblies with the same name, version, culture and public key token, but different processor architecture. This is necessary because in .Net framework redist we will install platform specific assemblies with the same name, version, culture and public key token, like CustomMarshalers.dll. Theoretically, we can change the version number of one of the assemblies, so that each assembly will have different version number. But that will cause far more confusion than do good. Just imagine that in x86 the version is 1, and 2 in AMD64, 3 in IA64. It will almost impossible to write portable code.

So now conceptually there is one GAC for each processor architecture. We will block installation of incompatible processor architectures (like you can't install 64 bit only assemblies in x86, and you can't install AMD64 assemblies in IA64, etc.). So the number of GAC you will see is less than possible processor architectures. Specifically, on x86 machine, there are 3 GAC: One for 32 bit only assemblies, one for portable assemblies, and one for v1.0/v1.1 assemblies who do not have processor architecture. On 64 bit machines, there is one more for 64 bit only assemblies.

Warning: The following paragraph is implementation detail, and may change without notice.

If you cd to GAC (%windir%\assembly), you will see GAC, GAC_32, and GAC_MSIL. There are corresponding to v1.0/v1.1 assemblies, 32 bit only assemblies, and portable assemblies.

At assembly loading time, when we probe GAC, we will first try the platform specific GAC(32 bit GAC on 32 bit process, and 64 bit GAC on 64 bit process), then the portable GAC, and last fall back to v1.0/v1.1 GAC. In another word, we will automatically find the right assembly. There is absolutely nothing you need to do to make that happen.

Published Sunday, September 12, 2004 11:51 PM by junfeng
Filed under: ,

Comments

# re: GAC, Assembly ProcessorArchitecture, and Probing

Monday, September 13, 2004 3:11 AM by Kevin Westhead
Can you clarify what "portable assemblies" are?

# re: GAC, Assembly ProcessorArchitecture, and Probing

Monday, September 13, 2004 5:57 AM by Kevin Westhead
Oops, I see you already explained portable assemblies in your previous post about ProcessorArchitechture that you linked to.

# Drag and Drop and GAC

Tuesday, November 02, 2004 11:56 PM by Nihit Kaul's WebLog

# Drag and Drop and GAC

Wednesday, November 03, 2004 12:00 AM by Nihit Kaul's WebLog

# Debugging Assemblies in the GAC

Monday, February 06, 2006 5:17 PM by using Colin.Bowern;

# A More Complete Stack Trace when Debugging Assemblies in the GAC

Monday, February 06, 2006 5:17 PM by using Colin.Bowern;

# When the GAC makes you gack (Part 2) [How something can be both IN and NOT IN the GAC at the same time]

Monday, March 27, 2006 7:05 PM by Delay's Blog

In Part 1 we investigated a curious tool failure and discovered that it's possible for something to...

# A More Complete Stack Trace when Debugging Assemblies in the GAC

Tuesday, October 24, 2006 11:39 AM by using Colin.Bowern;

Have you ever had the need to get line numbers from an exception stack trace for an assembly in the GAC? ...

# When the GAC makes you gack (Part 2) [How something can be both IN and NOT IN the GAC at the same time]

Friday, March 16, 2007 9:08 PM by Delay's Blog

In Part 1 we investigated a curious tool failure and discovered that it's possible for something to be

New Comments to this post are disabled
 
Page view tracker