When is a GAC not a GAC

I’ve kicked around VS2010 a bit but still mostly work with VS08.  At the moment I’m upgrading some VS08 solutions to VS10 and in the process targeting .NET 4.0 and running post build events to GAC assemblies.  I take a look at C:\windows\assemblies and my assemblies aren’t there.  Thinking something is wrong with my post build event I drag the assembly into the GAC.  No errors, still not there.  So I fire up the VS command prompt and run GACUtil.  Everything is successful but when I check c:\windows\assembly it’s still not there.

Looking closer at the VS2010 command prompt I note its using the 4.0 framework version of GACUtil.  After a bit more investigation I find that we have a new GAC with .NET 4.0.  C:\Windows\Microsoft.NET\Assembly.  That’s where my assemblies are going.  So much for “GLOBAL” assembly cache.

So why?  The .NET 1.1 and 2.0 runtimes shared the same global assembly cache allowing an assembly compiled for 1.1 to load an assembly compiled for 2.0 leading to one very unhappy CLR.  So why didn’t Microsoft do something with .NET 3.5?  Basically .NET 2.0 and 3.5 use the 2.0 CLR so in turn use the same GAC.  For the first time since .NET 2.0 we have a new CLR and in order to not repeat the mistakes of the past CLR 4.0 has a private  GAC.  CLR 2.0 assemblies can’t see CLR 4.0 assemblies.  End result, we now have two GAC’s.  Well that’s my ham fisted explanation…

This entry was posted in .NET. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s