GAC DLL HELL

[G Dean Blake]

I wrote a web component called GP and gave it a strong name. When I deploy
my ASP application to another web server and put GP.dll in \mywebroot\bin
and include a reference to that location, everything works fine. But if I
don't do that and instead install my GP.dll into the GAC on the target web
server, then my dll can't be located. I figured that I would also need to
make a reference to GP.dll in the GAC but with vs.net that doesn't seem to
be possible because when you browse to the GAC it won't let you make a
reference to anything in the GAC.

As best I can tell this is not working according to the docs or the books.
Anyone know how to do this?

Thanks,
G

 

[Alvin Bruney [MVP]]

MSDN has an article instructing users how to make a GAC based assembly
visible in visual studio. I'm sorry, i no longer have a link to that article
but it shouldn't be difficult to find.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok

 

[Ken Cox [Microsoft MVP]]

I think Alvin may have been referring to this:

How to display an assembly in the Add Reference dialog box

http://support.microsoft.com/default.aspx?scid=kb;en-us;306149

I usually just keep a local copy in my project and reference it there. At
runtime, .NET will use the GAC copy first.

Ken

 

[G Dean Blake]

I noticed where it says...

It is highly recommended that you not install your assemblies to the GAC.

Is this something that just doesn't work now but will work later?
G

 

[Juan T. Llibre]

re:

It is highly recommended that you not install your assemblies to the GAC.
Is this something that just doesn't work now but will work later?

It works fine now, and will work fine later.

That warning is there, if you don't want to share your
assemblies with other applications running on that system.

Placing your assemblies in the GAC makes those
assemblies available to *any* application in the box.

That raises privacy issues, particularly in
shared environments, like hosting providers.

OTOH, if it's *your* box, and it only runs *your* applications,
there's no problem with placing your assemblies in the GAC.

 

[Ken Cox [Microsoft MVP]]

Hi Dean,

Shared assemblies belong in the GAC. Otherwise, they are private to one app
and should be put in the /bin folder. Not sure why the strong warning
because it works fine as long as they have strong names.

Ken

 

[G Dean Blake]

Maybe I don't understand....

That article said that I can put my dll into the GAC but to make it work it
also has to also be in my local \BIN directory because a vs.net project
can't reference the GAC. So, if I have to have a copy in each asp
application's local directory why use the GAC at all?

It seems strange to me that dlls in the GAC can't be used !! Why put stuff
there if it can't be used ??

I'm obviously missing something here
G

 

[Juan T. Llibre]

Are you confusing *referencing* a dll in your project,
with your web application ( or windows form )
*calling* the same dll in the GAC ?

Just because you can't *reference* the dll in your project,
doesn't mean that your applications can't find a dll in the GAC.

The GAC path is built into ASP.NET.
It's also built into Windows Forms apps.

See
http://msdn.microsoft.com/library/d...ide/html/cpconhowruntimelocatesassemblies.asp
for further reference.

There's absolutely no problem with a web or windows forms
application finding an assembly which is located in the GAC.

 

[G Dean Blake]

BUT......

It seems to me that if the GAC is built into ASP.NET that ASP.NET should be
able to find a dll there (which was what started this thread)

Saying that we have to put another copy of our dll somewhere else and
reference it there so that it can find the real copy in the GAC sounds like,
well, something is not optimum

G

 

[Juan T. Llibre]

It's *not* ASP.NET which can't find the
dll in the GAC, in order to reference it.

It's VS.NET.

This is by design.

The reason is that an assembly installed in the GAC in *your*
development machine is not necessarily the same as what other
users of your application might require.

Letting VS reference assemblies installed in a
development machine would lead to a quick mess.

When you build your application, you want your dependencies
to be deterministic. You can't guarantee that if, when VS starts,
it can reference assemblies in the GAC of the machine it's installed in.

If you have v1 in your GAC, and I have v2 in my GAC and both
you and I rebuild the same solution, your app will depend on v1,
while my app will depend on v2. End result : failure.

This would lead to very interesting/loud programmer complaints...

It's counter-intuitive, but very logical if you think about it a bit.