When to use the GAC and how. ?

  • Thread starter Thread starter Mark
  • Start date Start date
M

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
 
Mark said:
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?
Click to expand...

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?
Click to expand...

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?
Click to expand...

Normaly only if the Assembly is in GAC.

thanks in advance.
Mark
Click to expand...

you're welcome, Günter
 
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
 
Back
Top