Menu
.NET has this concept of Application Domains which from what I understand can be used to load an assembly into memory. I've done some research on Application Domains as well as go to my local book store for some additional knowledge on this subject matter but it seems very scarce.
All I know that I can do with Application Domains is to load assemblies in memory and I can unload them when I want.
What are the capabilities other that I have mentioned of Application Domains? Do Threads respect Application Domains boundaries? Are there any drawbacks from loading Assemblies in different Application Domains other than the main Application Domains beyond performance of communication?
Links to resources that discuss Application Domains would be nice as well. I've already checked out MSDN which doesn't have that much information about them.
419
An application domain is the segment of reality for which a software system is developed. It is the background or starting point for the actual-state analysis and the creation of a domain model. An application domain can be an organization, a department within an organization, or a single workplace.
Process A runs managed code with one application domain while Process B runs managed code has three application domains. Note that Process C which runs unmanaged code has no application domain. Code and data are safely isolated using the boundary provided by the AppDomain.
AppDomains are created by the . Net runtime when a managed application is initialised. When you start ABC. EXE, it gets an application domain.
An application domain is a logical isolation boundary created around . NET applications so that applications do not access or affect each other. It is a light-weight process having its own set of code, data, and configuration settings.
AppDomains best visualized as a very light weight process.
There can be N AppDomains per .Net Process but generally speaking there is only one. The real advantage of AppDomains is they provide an isolation boundary within your process. Objects can only talk to each other across an AppDomain boundary via remoting or serialization.
It's also possible to run 2 AppDomains at completely different security levels within a process. This can allow you to run your main application at Full Trust while running Untrusted Plugins at a much lower trust level.
It's hard to blanket say yes or no to whether or not a thread respects an AppDomain. It's possible for a single thread to be in N different AppDomains. Such a situation is possible if an object in one AppDomain makes a remote call to an object in another AppDomain. The thread will have to transition between the AppDomains in order to complete.
The disadvantage of AppDomains is mainly complexity. Remoting can take a little bit of time to get your head around and properly setting up an AppDomain can be a non-trivial process.
You may want to take a peek through the MSDN documentation on AppDomains. It's hard to find a succint tutorial that describes them because they have a variety of complex features. This provides a nice overview which if it doesn't answer your question directly will at least point you in the right place.
http://msdn.microsoft.com/en-us/library/cxk374d9.aspx
This document is no longer maintained please refer to this for the updated version: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx
110
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
