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.

Comments

• Anonymous
  September 12, 2004
  Can you clarify what "portable assemblies" are?
• Anonymous
  September 12, 2004
  Oops, I see you already explained portable assemblies in your previous post about ProcessorArchitechture that you linked to.
• Anonymous
  March 27, 2006
  
  In Part 1 we investigated a curious tool failure and discovered that it's possible for something to...
• Anonymous
  October 24, 2006
  The comment has been removed
• Anonymous
  March 16, 2007
  In Part 1 we investigated a curious tool failure and discovered that it's possible for something to be