OK,

I just had a long conversation with a co-worker on this and we
are looking for the answers to the following question:

Where do .Net Assemblies based on class libraries (DLLs) that are
strong named execute and where do non-strong named assemblies execute.

Logic tells me that since they are basically DLLs, they must load
in their calling process' memory space and execute there.

-----------------------I think this is where it gets
fuzzy----------------

However, I have seen reference to the CLR checking, when a GAC
assembly is requested, to see if that assembly has already been
previously loaded into the CLR and if it has, using the version that
already loaded.

Is this correct? If so, does this only happen for strong named
DLLs assemblies or does it happen for all assemblies? Any help would
be GREATLY appreciated.

There can be multiple AppDomains with a win32 process. Each AppDomain can
make references to assemblies within that AppDomain. If an Assembly is
strong named, then the CLR can be sure that any calls to that assembly from
other AppDomains within that process will be requring the same assembly, so
it simply shares that assembly. If an assembly is not strong named, no such
guarantee exists, so I think(?) that each AppDomain gets its own copy.

This is a little different from standard Win32/unmanaged DLL's that are
global and shared between apps once loaded. Because of the public key (ie.
strong name) of a strong named assembly, the CLR can be assured that
requests on this assembly are definitely for this assembly. Non strong named
assemblies will be checked for a less strict set of criteria, and so an
assembly can be named the same with the same version number, but actually be
from different sources and do different things (therefore each AppDomain
will load its own local copy). Strongly named assemblies are uniquely
identified via the strong name.

I hope I haven't rambled too much and thats how I understand it. I would
welcome any clarificaiton though.

- Paul Glavich

[quoted text, click to view]

I don't know if the first poster answered your question, but generally
speaking if the runtime will always check if an assembly has been loaded
into runtime before trying to explicitly load it again.

If the assembly has not been previously loaded, then strict versioning is
used if versioning (strong name) is being used, otherwise it grabs the
latest version. Remoting aids a little twist to this.

ice
[quoted text, click to view]

Well,

I believe we are all still saying the same thing but I want to make
sure. The only thing - even in the context if .Net that can request an
allocation of memory is an EXE. If an EXE needs a dll, the dll's
executable code will load into the EXE's memory space and execute there.
Is this scenario still accurate on the .Net world. I am asking because
some members of my team seem to be indicating that the strong named DLLs
can exectually execute in GAC (at least if I understand what they are
trying to say correctly.). I do not believe this is the case and was
simply looking for some documentation that states exactly how the
process works for .Net Exe and Dll assemblies.

Thanks
George

*** Sent via Developersdex http://www.developersdex.com ***

OK,


I guess I am getting hung on what is an AppDomain. I have looked for
a good article from MS that describes it but have not found one. Any
suggestions?

Thanks
George

*** Sent via Developersdex http://www.developersdex.com ***

Sorry for not being very clear. As Ice mentioned, I beleive that the .Net
runtime will share the strongly named assemblies across appDomains and not
reload this assembly for each appDomain. It doesn't strictly run in the GAC,
it gets loaded from there.

Assemblies that are not strong named are not shared across appDomains. There
is no guarantee that an assembly named 'foo' with a version of 1.0.0.1 is
the same in appDomain1 as it is in appDomain2 (ie. might be named and
versioned the same but be completely different authors and functionality).
Strong naming makes it unique therefore binding to it (by strong name) is
guaranteed.

- Paul Glavich.
Microsoft ASP.NET MVP.


[quoted text, click to view]

I dont have a link handy for a Microsoft definition of what an appDomain is,
but a good way of thinking about it is that its a .Net version of a standard
Win32 process. The CLR provides a more finely grained method (than the std
Win32 process) of isolation known as the Application domain. It is
equivalent to a standard Win32 process in concept only, in that the
appDomain provides isolation between .Net applications/processes. A single
Win32 process can actually host multiple .Net appDomains though so in
practice they are different, but provide roughly the same features.
appDomains fall under the control of the CLR/.Net runtime though and as
such, have the added benefits of managed environment. So basically logical
units of execution within the .Net managed space.

Try this link :- http://www.andymcm.com/dotnetfaq.htm#4.1

- Paul Glavich.

[quoted text, click to view]