6

After installing .Net 4 and getting some questions that were already answered here I also realized how the Framework dlls are repeated in several places for the different Framework versions (this is not new, it happens with previous versions, but hadn't paid attention to it until now)

1 - GAC: %systemroot%\assembly

2- Framework installation directory: %systemroot%\Microsoft.NET\Framework\v...

3- and if you have the Windows SDK installed, also in: C:\Program Files\Microsoft SDKs\Windows\

I think the last ones are the so called "Reference Assemblies" and have extra metadata to aid Visual Studio, but

what about location number 2? Why are assemblies repeated there?

Community
  • 1
  • 1
Xose Lluis
  • 895
  • 1
  • 9
  • 8

2 Answers2

2

  1. No, that's the GAC location for .NET 1.x through 3.5. The GAC for 4.0 is located in c:\windows\microsoft.net\assembly. Why it was moved isn't clear, probably to avoid trouble with projects that referenced assemblies directly from the GAC, a big no-no but it has been done.

  2. Yes, reference assemblies live there. Also in c:\program files\reference assemblies. They are initially verbatim copies of the assemblies stored in the GAC. Until you deploy some kind of hotfix. Keeping them separate ensures that you build programs that target the "proper" framework assemblies, not what you happen to have stored in your GAC.

  3. Yes, no framework assemblies are there, just build tools.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • @Jared, many thanks for your answers. Why we have assemblies both in the SDK folder and the Framework folder continues to be strange, even more if file sizes seem the same. For the duplication between GAC and other folders that seems to make more sense to me now. – Xose Lluis May 18 '10 at 08:48
1

This is more of an educated guess than an actual answer but ...

In order to initially GAC a DLL you need to have a full DLL (aka not-reference assembly) for the GAC to use. The reference assembly won't work as it doesn't have executable code. Hence you need a real DLL in which to source the GAC so you get location #2.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • No, reference assemblies are verbatim copies, including the code. – Hans Passant May 17 '10 at 19:34
  • @Hans, true reference assemblies are not verbatim. They have all of their IL bodies stripped out and are not runnable. I cannot remember off the top of my head if the SDK assemblies installed in Program Files are actually true reference assemblies or just referred to as such. – JaredPar May 17 '10 at 22:05
  • Example: c:\windows\microsoft.net\framework\v2.0.50727\system.dll: 3178496 bytes. GAC version: c:\windows\assembly\gac_msil\system\2.0.0.0__b77a5c561934e089\system.dll: 3178496 bytes. What was stripped? – Hans Passant May 17 '10 at 22:29
  • @Hans, the versions under c:\windows\Microsoft.Net won't ever be reference assemblies. They will be full .Net assemblies. I'm refering to the ones under c:\program files. And I believe they weren't reference assemblies until 4.0 either – JaredPar May 17 '10 at 23:10
  • c:\program files\reference assemblies\microsoft\framework\v3.5\system.net.dll: 237568 bytes. c:\windows\assembly\gac_msil\system.net\3.5.0.0__b03f5ff115d50a3a\system.net.dll: 237568 bytes. You are closer to the fire than anyone around here. What is *really* going on? – Hans Passant May 17 '10 at 23:18
  • @Hans, that is still the 3.5 install. I'm not sure we supported true reference assemblies until 4.0. That being said I don't particularly know why we do this. I'm asking around though to see if there is a reason for this. – JaredPar May 18 '10 at 02:25
  • I do see 4.0 dups, both stripped and verbatim. Please also ask for the tool they used, it should be popular with the tool vendors. – Hans Passant May 18 '10 at 09:00