Strongly-named assemblies not in GAC

[Kyle Blaney]

What happens when a strongly-named assembly is not in the global
assembly cache (GAC) but is installed in two application's bin
directories (with each copy being identical in every way - the exact
same version, public key, culture information, etc.)?

I understand the benefits of deploying shared assemblies with each
application instead of using the GAC but is increased memory usage a
disadvantage of this approach? For example, suppose that the first
application is running and the shared assembly is in memory. If the
second application is started and needs the same shared assembly is it
loaded in memory a second time?

Kyle Blaney

 

[Cowboy \(Gregory A. Beamer\)]

Yes. It is loaded a second time. IN reality, unless you are using static
methods (helper methods), you end up consuming memory whether in the GAC or
shared. You can create an assembly that loads into COM+ to pool objects, if
that is your goal, but I would not advise it.

Too many people are worried about memory usage, which is probably a leftover
from the COM days, when you had to worry. The GC handles memory rather
nicely, even if it does seem to allow .NET to consume too much. As
everything performs nicely, I would not be overly worried.

Back to the question. Strong-naming, outside of the GAC, simply means you
have a strong name. Two apps, using the same code base, will instantiate
objects from assemblies in their own apps; they do not share.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************

 

[Kyle Blaney]

Greg,

Thank you for your reply. Let me make sure I understand what you're
saying.

Even though I shouldn't really be worried about memory usage, it's
exactly the same whether I put the assembly in the GAC or copy it to
each application's directory. If that's the case, what is the
advantage of using the GAC?

The only advantage I can see is one of maintenance. If I ever have to
provide a new version of the assembly I only have to deploy a single
copy. However, even that is a stretch because I have to update each
application's config file (if I don't use publisher policy) to ensure
they use the new version of the assembly.

Kyle Blaney