Is there a way to join or hook into an existing AppDomain? I guess
I'm looking for something similar to AppDomain.GetAssemblies, but that
would probe the system and return references to all the AppDomains
currently running on the app server so a client could tie into that
AppDomain, load assemblies, etc.

We will have hundreds and hundreds of web users hitting our web
server. Because of certain unique business processes, we have dynamic
assemblies getting created all over the place for each one of these
web users. Loading all these assemblies into the default AppDomain
aspnet_wp.exe is running in is not a good choice because we can't
unload assemblies from that AppDomain without bringing down the ASP
process which boots off all currently attached users.

We decided to look into creating a new AppDomain which would have all
these assemblies loaded into and run from. We can bring down that
separate AppDomain to free all the assemblies without messing with the
web users' session when they are accessing other parts of our website
that have nothing to do with these special dynamic assemblies. In
some preliminary testing, creating an AppDomainSetup object and using
that in AppDomain.CreateDomain("SomeDomainName", ...) gives us our
separate AppDomain to which we can load and run assemblies, BUT then
each new web user that comes along and hits that
AppDomain.CreateDomain("SomeDomainName", ...) line of code appears to
create a new AppDomain.

I guess I thought that if an AppDomain existed with a certain name
(i.e. "SomeDomainName") and then another user came along to create
another "SomeDomainName" domain, that object would bind to the
existing "SomeDomainName". Setting up PerfMon to check aspnet_wp .NET
CLR Loading objects, I see the current assembly count increasing each
time AppDomain.CreateDomain gets hit.

I'd hate to have to create a new AppDomain for each web user hitting
that section of code. Seems the performance would degrade through the
sheer number of domains being created and we'd be worse off than our
current situation of assemblies gone wild in the default domain being
unable to unload them.

Maybe there is some way to have a new AppDomain created via the
Application_Start event? If so, how can user sessions join into the
AppDomain that was created in Application_Start? Or if we can't use
an Application_Start technique, is there some overloaded method of
CreateDomain that I'm not seeing that will create the AppDomain if it
does not currently exist or "join" it if it does exist?

Thanks in advance.

-Mike

Mike,

There is no way to enumerate existing AppDomains from within managed code -
you must maintain a reference to the AppDomain when you create it. The only
AppDomain you can get hold of is the one in which your code is running by
calling AppDomain.CurrentDomain.

Also, as you have found out creating an AppDomain with the same name creates
a new instance, it does not return a reference to the existing AppDomain.

There is no way to join an AppDomain as you describe it. If you have a
reference to the AppDomain, you can load/execute assemblies in it,
instantiate objects and call their members.

Regards
Allen

"Mike" <mmalick (AT) earthlink (DOT) net> wrote

Thanks for the answer Allen...I think. :-( Not what I wanted to
hear, but oh well. I'll try and attack this some other way such as
holding on to an AppDomain reference and use that reference for every
user session in the web app.

Don't know if Microsoft is scanning this newsgroup, but I'm having a
hard time understanding why these are not basic pieces of
functionality provided by the .NET Framework. Why can you create
AppDomains, but not be able to come in after the fact to interrogate
the system and enumerate existing AppDomains? Seems like a reasonable
piece of functionality to have. Is it some sort of technical
limitation? And while we're on that suject, we all see posts
everywhere in these newsgroups about people asking how to unload an
assembly loaded into an AppDomain. The answer is, unfortunately, you
can't! You can only bring down the AppDomain that is holding those
assemblies. If we can create assemblies and enumerate assemblies in
an AppDomain (i.e. AppDomain.GetAssemblies), why on Earth can we not
programmatically unload them with messing with the whole AppDomain??
Ok...enough of that.

Thanks for the info Allen. I'm sure we'll find a workaround.

-Mike

"Allen Jones" <agj (AT) bigfoot (DOT) com> wrote

Mike,

I seem to remember the reason you cannot enumerate AppDomains is for
security purposes. However, I never quite bought that because if that was
the case then surely the functionality could be protected using CAS.

Re unloading assemblies, I have heard that this will change in a future
version of the framework.

It would of course be interesting to hear from MS on both these points.

Regards
Allen

"Mike" <mmalick (AT) earthlink (DOT) net> wrote

Mike,

Have you look at turning on AppDomain shadow copy?
AppDomainSetup.ShadowCopyFile = true will turn it on. When it is on, the
assembly is copied to the download cache so that the original assembly is
not locked.

You may also play with
AppDomainSetup.DynamicBase/ShadowCopyDirectories/CachePath for differnt
combinations. The properties are explained in MSDN.


"Mike" <mmalick (AT) earthlink (DOT) net> wrote