-1

Initially, we were working on .Net Framework 3.5. Hence the GAC path was hardcoded in code as 

C:\Windows\assembly\GAC_64\{0}\1.0.0.0__008145f79b9aec14\{0}.dll

Later we migrated to .Net Framework 4.0. Now the required path should be 

C:\Windows\Microsoft.NET\assembly\GAC_64\{0}\v4.0_1.0.0.0__008145f79b9aec14\{0}.dll

Currently the problem can be fixed by putting the second path in my code. But when Microsoft releases its next set of frameworks, it might fail.

So i wanted to know if there are any ways in which we can access GAC binaries independent of .Net Framework.

Any comments on this will be helpful. Thank you

Adriano Repetti
  • 65,416
  • 20
  • 137
  • 208
Manjunath K Mayya
  • 1,078
  • 1
  • 11
  • 20
  • 2
    Can you please explain what drove you to this solution? Why do you need the path to the assembly? Why do you assume Windows is in C:\Windows? – CodeCaster May 09 '12 at 10:56

2 Answers2

5

If you want to load an assembly from the GAC, load it by using its fully qualified name: 

Assembly.Load("SampleAssembly, Version=1.0.2004.0, Culture=neutral, PublicKeyToken=8744b20f8da049e3");

If it's found in the GAC, it will be loaded from there.

You should never ever hardcode the path of the GAC anywhere. It could change at any time, even between service packs or patches, and it's an implementation detail that you cannot rely on.

Botz3000
  • 39,020
  • 8
  • 103
  • 127
  • I hope he doesn't need to _load_ the assembly but simply to inspect it (reading metadata as, for example, Reflector does?) – Adriano Repetti May 09 '12 at 11:04
  • My assembly "SampleAssembly.dll" is sitting in path. C:\WINDOWS\Microsoft.NET\assembly\GAC_32\SampleAssembly\v4.0_1.0.0.0__008145f79b9aec14In code i'm trying to use Assembly.Load("SampleAssembly.dll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=008145f79b9aec14"); But this doesnt seems to be working. What could be wrong with this? I also tried removing .dll from assembly.Load, but it still didnt work. – Manjunath K Mayya May 09 '12 at 12:02
  • @ManjunathKMayya enable Fusion log, you'll see what it's trying and what doesn't work – Adriano Repetti May 09 '12 at 12:43
  • @ManjunathKMayya If you load the Assembly as previously, you can get Assembly.FullName from it to retrieve the fully qualified name. You can use that name to load the assembly the way i explained above. After that, throw away the hardcoded paths. – Botz3000 May 09 '12 at 13:12
  • 1
    @ManjunathKMayya moreover if it's in the GAC why you can't simply add a reference? – Adriano Repetti May 09 '12 at 14:20
  • @Adriano: Just because it is in the GAC, doesn't mean that it will appear in the Add Reference dialog. – Chris Dunaway May 09 '12 at 15:43
  • @ChrisDunaway I can't imagine a reason it won't! :| – Adriano Repetti May 09 '12 at 15:52
2

DO NOT HARDCODE THEM

I guess you do not need to load the assembly using its path in the GAC (there would be a big big Why for this) so maybe you have to inspect the binary file by hand without loading it (for example to list available assemblies or to inspect their metadata).

If you need to access the GAC do not rely on paths, it'll be the hell for you (Windows directory changes, GAC structure isn't trivial and effective path depends on environment, assembly type and more).

There is an unmanaged API to work with this: look here on MSDN for reference. For example to get the path of the GAC you may write:

GetCachePath(ASM_CACHE_GAC, pPath, MAX_PATH);
Adriano Repetti
  • 65,416
  • 20
  • 137
  • 208