AppDomain 在 C # 中的应用

The single most important use is that your code has to have one - i.e. everything you write in C# executes in an AppDomain. That is quite important ;-p

If you mean additional app-domains:

When using plugins and other untrusted code, it allows you both isolation, and the ability to unload them (you can't unload assemblies - only entire app-domains).

I'm using it currently to load dynamically generated dlls, so that I can unload them.

They also allow you to set different configuration files, trust levels, etc - but have associated costs of complexity and remoting.

MSDN has a section on app-domains, here.

I can't tell you what the most important use is, since that depends on the situation.

AppDomains are useful for sandboxing parts of your application. You can load extensions in an AppDomain and unload them again - something you cannot otherwise do. You can assign specific rights to AppDomains. Per default objects in different AppDomains cannot access each other.

AppDomains can be viewed as lightweight processes as they give you many of the same features. However, unlike a Process new AppDomains do not have their own thread per default. You have to manage AppDomains and threads yourself.

Also, AppDomains all share the same managed heap. This is usually not a problem, but it may have surprising effects as some instances like strings are shared among AppDomains. For regular use this is not an issue, but if you use strings for locking, threads in different AppDomain can affect each other.

In general, it's not so daily coding practice to use AppDomains, this could be considered something as an advanced concept.. but, starting from this simple thing, it's important to better understand concepts behind the word "AppDomain".

In terms of architecture, and taking it simple as possible, an AppDomain is an isolation container even in terms of memory addressing, inside it all the assemblies needed by an application are loaded and executed, even if this concept is more complicated to explain in details (I hope it's not about yor question to going so deeper).

Starting from there, the AppDomain class first of all is used to obtain access to the application related executing application domain, this could be done via the Singleton property implementation AppDomain.CurrentDomain. In this way it's possible to:

1. obtain access the loaded assemblies;
2. obtain access to the appdomain-shared data slots;
3. intems marshalling, in terms of unwrapping created instances from loaded assemblies in created domains.

Then, the AppDomain class is used to:

1. create more "domains" in the same process;
2. executing assemblies in the process;
3. manage the appdomain's loading/unloading process.

It could be useful to take a view of the code of the new Microsoft framework (not yet released) MEF (Managed Extesibility Framework) which is truly based on concepts like AppDomains creations and unload, dynamically loaded assemblies.

As a simple example of things and examples of what you can do with AppDomains, I can share this link.

I hope I answered your question.

A C# AppDomain is a logically isolated container inside which .NET code run. When you run any .NET code it always runs in a default appdomain.

Do watch this 30 minutes youtube video What is C# AppDomain ? which explains AppDomain in more detail.

But let me still try to explain in more detail. Lets say you get a third party DLL and you want to use it in your application. But you also suspect that the third party can have some malicious code so you would like to run the third party DLL in a constrained environment. Like you do not want the third party to access your c: drive or delete files and so on.

So you can create two AppDomains one which is for the third party and one for your own C# classes. For the third party appdomain you will apply security constraint that it can not access c: drive and for your C# DLLs you will have a unrestricted app domain.

Please read my blog for standard application of runtime loading of DLLs and cross-communication using AppDomain. https://blog.vcillusion.co.in/sending-events-through-application-domain-boundary/

1. Runtime Loading and unloading of DLLs: I worked on a project where DLLs are loaded at runtime by the user, and during program execution, the methods are executed using Reflection and unloaded during the program run.
2. Securing my Main Execution Program: We are loading the DLL dynamically so any exception that occurred in that dynamically loaded DLL didn't affect my main AppDomain. In case of corruption scenarios, we have the option of efficiently unloading and loading the DLL again.
3. Cross-AppDomain Communication: We can dynamically load any two DLLs at runtime in different AppDomain and make them communicate with each other.