4

There have been several questions that have answered the HOW or more precisely how to get around this Visual Studio limitation:

GAC Assembly Missing in Add Reference dialog How can I reference a dll in the GAC from Visual Studio?

The MSDN documentation though says:

You cannot add references from the Global Assembly Cache (GAC), as it is strictly part of the run-time environment.

So it seems that the Visual Studio team did this on purpose. Maybe they did this so you don't hurt yourself? What best practice am I violating by referencing an assembly in the GAC using an VS extension like this? Am I missing something?

Just double-checking with the community, appreciate your thoughts.

Community
  • 1
  • 1
LeWoody
  • 3,593
  • 4
  • 25
  • 31

3 Answers3

3

It doesn't actually stop you from doing this. In particular for .NET 4.0, you can use the Browse tab to access c:\windows\microsoft.net\assembly. The shell extension handler that stops you from accessing the .NET 2.0 GAC through the shell dialogs isn't included for 4.0

But yeah, that's a really bad idea. The GAC is a deployment implementation detail, you cannot presume that the content of your GAC will match the content on another machine. Only a reference assembly can give you a stable set of type definitions that don't change when, say, you get a security update through Windows Update.

This is even more relevant for .NET 4.0. Its reference assemblies are special. They are no longer a copy of the assemblies you might find in the GAC or in c:\windows\microsoft.net. They only contain metadata, no IL. This allows Microsoft to deploy updates that change the public types in the assemblies. Something that went badly wrong in the .NET 2.0 service packs (WaitHandle.WaitOne(int) for example).

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
3

With Sharp Develop (which is an open source IDE for .NET) you could add GAC references, with .NET 4 you could add GAC references. You definitely won't hurt yourself by adding GAC references. I don't have any negative feedback from developers using it.

Soon this extension will have more sexy features.

Drew Gaynor
  • 8,292
  • 5
  • 40
  • 53
BALKANGraph
  • 2,031
  • 1
  • 15
  • 16
1

Because the GAC can have more than one version of a given Assembly, so it will get very complex very quickly. It is easier to require that a copy of the version you wish to reference is in a normal folder.

(Most of the time you should not be using the GAC as it is as much of a pain as the Register was in COM’s days.)

Ian Ringrose
  • 51,220
  • 55
  • 213
  • 317
  • Thanks for your answer. I feel like referencing an assembly in a normal folder doesn't take away the problem of managing multiple versions of an assembly. If I keep all my third-party assemblies in a local folder, say "c:\assemblies", I need to make sure that all my developers have the right version of the third-party assemblies on their machines... or they could make a reference to a wrong version. Same with deployment... if I kept all my assemblies on "c:\assemblies"; the problem does not go away... it is simply moved. The GAC is a local folder with added capabilities that helps. – LeWoody Nov 24 '10 at 17:32
  • 1
    @LWoodyii, just check the correct version of each assembly into your source code control system and use a relative path to reference them. – Ian Ringrose Nov 24 '10 at 23:07