Menu
I'm fairly new to reflection and I was wonder what I would use a (second) AppDomain for? What practical application would one have in a business application?
236
App domain can be used to manage multiple versions of an application. An application domain is a virtual process environment that provides a isolation boundary for an application. This boundary allows multiple versions of an application to be run on a single computer.
A process is an executing application (waaaay oversimplified). A thread is an execution context. The operating system executes code within a thread. The operating system switches between threads, allowing each to execute in turn, thus giving the impression that multiple applications are running at the same time.
The CurrentDomain property is used to obtain an AppDomain object that represents the current application domain. The FriendlyName property provides the name of the current application domain, which is then displayed at the command line.
The AppDomain class implements a set of events that enable applications to respond when an assembly is loaded, when an application domain will be unloaded, or when an unhandled exception is thrown. For more information on using application domains, see Application Domains.
There are numerous uses. An secondary AppDomain can provide a degree of isolation that is similar to the isolation an OS provides processes.
One practical use that I've used it for is dynamically loading "plug-in" DLLs. I wanted to support scanning a directory for DLLs at startup of the main executable, loading them and checking their types to see if any implemented a specific interface (i.e. the contract of the plug-in). Without creating a secondary AppDomain, you have no way to unload a DLL/assembly that may not have any types that implement the interface sought. Rather than carry around extra assemblies and types, etc. in your process, you can create a secondary AppDomain, load the assembly there and then examine the types. When you're done, you can get rid of the secondary AppDomain and thus your types.
186
99% of the time I would avoid additional AppDomains. They are essentially separate processes. You must marshal data from one domain to the other which adds complexity and performance issues.
People have attempted to use AppDomains to get around the problem that you can't unload assemblies once they have been loaded into an AppDomain. So you create a second AppDomain where you can load your dynamic Assemblies and then unload the complete AppDomain to free the memory associated with the Assemblies.
Unless you need to dynamically load & unload Assemblies they are not really worth worrying about.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
