Dependency problem between AppDoamins.

[James X. Li]

Hi everyone,

I want to add a feature to my C# application to allow it to
duplicate itself, just like the ctrl-N key to cause the Internet Explorer to
duplicate its window. I could easily implement this feature by starting
the application as a new process via a System.Diagnostics.Process.Start()
call.

But I have heard that AppDomain should provide a faster way to do this kind
of job. So I created an AppDomain in my application and used
ExecuteAssembly() to start the application in the new appdomain.
The application got restarted with a new window and worked
smoothly. However, the new appdomain is still dependent
on the parent appdomain : if I close the parent appdomain, all child
appdomains got closed too.

My question is: Is there a way to make a child appdomain completely
independent from the parent appdomain?

Another problem is that, after the child appdomain opened its main window,
the parent appdomain stopped receiving shortcut key strikes for all menus.
If I closed the child appdomain, the shortcut keys for the parent appdomain
work again. This kind of dependency make AppDomain totally unsuitable for
my task. Or, did I do something wrong when creating the appdomains?

Thanks in advance,
James

 

[NuTcAsE]

The application got restarted with a new window and worked

smoothly. However, the new appdomain is still dependent
on the parent appdomain : if I close the parent appdomain, all child
appdomains got closed too.

This is the default behaviour of AppDomains. The first AppDomain that
the application launches is the default domain of the application, and
when that domain is shut down, all other app domains will also be torn
down.

My question is: Is there a way to make a child appdomain completely
independent from the parent appdomain?

One easy way (I'm calling it easy because the other alternative is
creating a custom CLR host which is a rather complex topic... but you
can read about it here...
http://msdn.microsoft.com/msdnmag/issues/01/03/clr/default.aspx) is to
not allow the user to be able to close the parent domain....

Create a shim application that will act as the loader for your main
application instances. When the shim app starts, it shows no interface,
but creates an AppDomain and calls ExecuteAssembly to start an instance
of your mail application. When a new instance is required to be opened
the shim application spins up another app domain.

While doing this the sim application keeps track of all app domains it
has created, and subscribes to the AppDomain's DomainUnloaded event.
When all domains are unloaded, the shim application terminates itself.

Theoretically the above approach should work, but I havn't tested this
out so its just a guess...

Hope this helps...
-NuTcAsE

 

[James X. Li]

Thanks for the help. It seems more complicated to fix than
I have expected. I have done some simple performance comparison
between process approach and AppDomain approach.
For my problem there is virtually no speed difference. The AppDomain
approach (without the necessary fixes) created only one process and saved
me about 5MB memory out of total 60MB. So, AppDomain is not very interesting
for my application.

James.