Reasoning for creating an appdomain

  • Thread starter Thread starter Kalpesh
  • Start date Start date
K

Kalpesh

Hello All,

What is the scenario in which creating & unloading appdomain (other
than the default appdomain) is required ?

Kalpesh
 
Kalpesh said:
What is the scenario in which creating & unloading appdomain (other
than the default appdomain) is required ?
Click to expand...

Unit testing is a good example. You want to be able to load all the
relevant assemblies into a new AppDomain, and then unload it when
you've run the tests so that you can recompile the assemblies under
test and run the tests again without restarting the unit test UI.
 
Thanks Jon,

How about winforms/asp.net app ?
What are the cases, where it will be better to create an appdomain &
load assemblies etc?

Kalpesh
 
Kalpesh said:
How about winforms/asp.net app ?
Click to expand...

It entirely depends on what they're doing. I wouldn't expect an ASP.NET
app to needs to create AppDomains separately themselves (each ASP.NET
app is within its own AppDomain itself, I believe) but a WinForms app
might.
What are the cases, where it will be better to create an appdomain &
load assemblies etc?
Click to expand...

If you need to keep a process running but start an awful lot of it
again from scratch, you might well want to use a "start-up" AppDomain
which loads the other one, and which can receive instructions to
restart (unload the current AppDomain and create a new one).

Another situation might be where you're loading plug-ins which you want
to be able to unload as well. Loading a plug-in within its own
AppDomain gives a level of separation from the "main" code which may be
valuable, and allows you to unload it later.

These are only examples, however - I'm sure other people have other use
cases. They should give you a flavour though.
 
Back
Top