6

I've noticed something strange about the location of .NET DLLs. I was trying to debug an issue with System.ServiceModel.dll, and I noticed that even though I have .NET 4.0 installed, only the 3.0 version of the ServiceModel DLL is installed in my GAC (I checked by exploring to C:\Windows\assembly). However, if I navigate to "C:\Program Files\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client" the 4.0 version is sitting right there. So why doesn't .NET install the 4.0 versions into the GAC?

And considering it doesn't, how do my 4.0 programs know where to find the 4.0 DLLs? Is the file path I gave above probed automatically? I looked back at my app that uses the 4.0 DLL to confirm that it does NOT copy the DLL locally, so it seems it must be getting it from either the GAC (and now I know the DLL isn't there), or probing in the .NETFramework folder. This has been really confusing me...

Edit: I followed MystereMan's advice and ran "Gacutil.exe /l System.ServiceModel", but it still only shows the 3.0 version. Does that mean the .NET 4 did NOT install the DLLs into the GAC after all?

Edit #2 and resolution: The gacutil.exe in my PATH is an older version that can't see the 4.0 assemblies. By searching my computer, I found the 4.0 version of gacutil.exe here: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools. Using that, I finally could see listed the 4.0 of System.ServiceModel.dll. Thanks all for the help!

Thanks,

-Robert

JoeCool
  • 4,392
  • 11
  • 50
  • 66
  • possible duplicate of [Gacutil.exe successfully adds assembly, but assembly not viewable in explorer. Why?](http://stackoverflow.com/questions/3054304/gacutil-exe-successfully-adds-assembly-but-assembly-not-viewable-in-explorer-w) – Hans Passant Jun 02 '12 at 00:03
  • This is not a duplicate -- I'm asking why the .NET Framework 4.0 DLLs don't seem to be in the GAC, not how to browse the GAC. – JoeCool Jun 04 '12 at 18:34
  • The *are* in the GAC, just not where you expect them to be stored. – Hans Passant Jun 04 '12 at 20:18
  • Fair enough, Hans. However, my case was still different since even when using gacutil (the default one that's in my PATH at least) I couldn't see the DLL, so it might be valuable to keep this open too. – JoeCool Jun 05 '12 at 15:30

1 Answers1

3

.Net 4.0 uses a different GAC, in Windows\Microsoft.Net\assembly.

The files in Reference Assemblies are empty stubs that are only used to filter IntelliSense in Visual Studio for different target frameworks.
If you open them in ILSpy, you'll see that all of the methods are empty.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • @Mehrdad: Which part are you asking about? There are reasons for both. – SLaks Jun 01 '12 at 22:16
  • 1
    So this begs the question, what is complete list of locations that comprise the collective thing we all like to call the GAC? Is it just Windows\assembly and Windows\Microsoft.Net\assembly? Or am I going to find out about another folder the next time I have a weird DLL reference error? – JoeCool Jun 01 '12 at 22:22
  • The one point of the GAC is that where the assembly exists is irrelevant. – moribvndvs Jun 01 '12 at 22:23
  • @JoeCool - you don't need to know where the GAC is, Microsoft provides tools to add things to the GAC. – Erik Funkenbusch Jun 01 '12 at 22:25
  • 1
    @SLaks: I was asking about why they changed the GAC location. There are *so many* darn locations for DLLs on the system -- since Program Files, Windows, and Windows\System32 weren't enough, we got Windows\WinSxS, Windows\Assembly, Program Files\Reference Assemblies, etc... and now they're changing the DLL location *again*, this time to Microsoft .NET\Assembly?! X__X – user541686 Jun 01 '12 at 22:34
  • @Mehrdad: To avoid compatibility issues with .Net 2.0 – SLaks Jun 01 '12 at 22:44
  • 1
    @SLaks: Wat? Wasn't the whole point of the GAC (strong names/versions and such) to fix these kinds of issues? Why would there be compatibility issues with 2.0? – user541686 Jun 01 '12 at 22:57
  • @MystereMan, ok, so how can I browse the GAC then? My initial issue was trying to determine if a client had the appropriate DLL for my program installed, so I went to C:\Windows\assembly to check. Since that doesn't cover the entire GAC, how can I browse it to check? – JoeCool Jun 02 '12 at 23:47
  • 2
    @JoeCool - `Gacutil.exe /l ` there is also the fusion.dll api http://support.microsoft.com/default.aspx?scid=kb;en-us;317540 – Erik Funkenbusch Jun 03 '12 at 05:20
  • @MystereMan, I followed your advice but still only see the 3.0 version (see edit to my original post). Any idea what that means? – JoeCool Jun 04 '12 at 18:35
  • @JoeCool - are you using the 4.0 version of gacutil? – Erik Funkenbusch Jun 04 '12 at 19:05
  • @MystereMan -- turns out I wasn't. It seems silly though that the version of the gacutil put into my PATH would be 3.0 rather than 4.0... that's annoying. Thanks for all the help though! – JoeCool Jun 04 '12 at 20:06
  • Alright, one more question. If I have a client that does not have the SDK installed (and it seems gacutil.exe is only a part of the SDK, not the regular .NET installation), what's the easiest way for me to tell if she has a DLL installed in her GAC? Search the two "assembly" folders for the specific name? Go ahead and install the .NET SDK to get gacutil.exe? Something else? – JoeCool Jun 05 '12 at 17:43
  • +1 for mentioning that "If you open them in ILSpy, you'll see that all of the methods are empty." The ones at C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ do have it. – Varun Sharma Dec 05 '12 at 00:41