When to use the GAC and how. ?

[Mark]

Okay, this is really a three part question. I'm trying to figure out how
this whole GAC thing works.

Here goes....

1. When should you put an assembly in the GAC as opposed to just referencing
the dll in a normal windows folder?

2. When you put it in the GAC how should you reference in the project? I
would think that you shouldn't have to reference it because it's in the GAC,
but it looks like you still do? If so, what's the benefit?

3. When should you set "CopyLocal" = False in the assembly reference
properties in VS.NET?

thanks in advance.
Mark

 

[Günter Prossliner]

Okay, this is really a three part question. I'm trying to figure out how
this whole GAC thing works.

Here goes....

1. When should you put an assembly in the GAC as opposed to just referencing
the dll in a normal windows folder?

Put an assembly into the GAC if it's shared between applications.

2. When you put it in the GAC how should you reference in the project? I
would think that you shouldn't have to reference it because it's in the GAC,
but it looks like you still do? If so, what's the benefit?

You must still reference the Assembly. The Compiler needs to get the
MetaData out of the referenced Assemblies.

How the Runtime Locates Assemblies:
-->
http://msdn.microsoft.com/library/d...ide/html/cpconhowruntimelocatesassemblies.asp

Assembly Binding Log Viewer (Fuslogvw.exe)
-->
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrffusionlogviewerfuslogvwexe.asp

3. When should you set "CopyLocal" = False in the assembly reference
properties in VS.NET?

Normaly only if the Assembly is in GAC.

thanks in advance.
Mark

you're welcome, Günter

 

[Josh Einstein]

I've actually found that I don't need the GAC anymore. When I first came
from the COM world I thought I was gonna need it all the time and I tried
using it for anything that was shared. But I found that the configuration
that is needed to ensure version compatibility is too much of a pain.

I still strong name my assemblies, but I've been using local copies of the
apps. The way I see it, I'm taking full advantage of the "DLL Hell"
solution. The DLLs are tiny and I don't have to worry about one change
breaking another.

While it is a hassle if a bug is found in the DLL, to update everything, it
is more so to manage the configuration to enable version compatiblity.

Though I understand if you're exposing a .NET DLL to COM clients, it needs
to be in the cache, I believe.

Josh