Usage of Appdomain in C#

Usage of AppDomain in 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.

What is AppDomain?

An AppDomain provides a layer of isolation within a process. Everything you usually think of as "per program" (static variables etc) is actually per-AppDomain. This is useful for:

• plugins (you can unload an AppDomain, but not an assembly within an AppDomain)
• security (you can run a set of code with specific trust levels)
• isolation (you can run different versions of assemblies etc)

The pain is you need to use remoting etc.

See MSDN for lots more info. To be honest, it isn't something you need to mess with very often.

What are app domains used for?

The basic use case for an AppDomain is in an environment that is hosting 3rd party code, so it will be necessary not just to load assemblies dynamically but also unload them.

There is no way to unload an assembly individually. So you have to create a separate AppDomain to house anything that might need to be unloaded. You can then trash and rebuild the whole AppDomain when necessary.

By the way, native code corrupting the heap cannot be protected against by any feature of the CLR. Ultimately the CLR is implemented natively and shares the same address space. So native code in the process can scribble all over the internals of the CLR! The only way to isolate badly behaved (i.e. most) native code is actual process isolation at the OS level. Launch mutiple .exe processes and have them communicate via some IPC mechanism.

Several AppDomains and native code

Yes it can be done but you should seriously measure if effort is repaid by benefits.

Windows won't load multiple copies of an unmanaged DLL and unmanaged DLLs are loaded per-process (not per AppDomain). What you can do is to create multiple temporary copies of same DLL then load them with LoadLibrary().

Each one will be loaded per-process but they'll be separated from each other (so they'll be thread-safe). All this stuff can be tied inside a class that wraps unmanaged calls (LoadLibrary, FreeLibrary, GetProcAddress and invocation itself). It'll use less resources and it'll be faster than multiple processes but you'll have to drop DllImport usage.

The only benefit I see is that this will scale much better than multiple processes (because it uses less resources) of course if you reuse instances keeping a cache (it's harder to keep a process cache than an object cache).

The advantages of using AppDomain in C# with Proxy Pattern?

Any given Windows process that hosts the CLR can have one or more application domains defined that contain the executable code, data, metadata structures, and
resources. In addition to the protection guarantees built in by the process, an application domain further introduces the following guarantees:

• Faulty code within an application domain cannot adversely affect code running in a different application domain within the same process.
• Code running within an application domain cannot directly access resources in a different application domain.
• Code-specific configurations can be configured on a per application domain basis. For example, you can configure security-specific settings on a per application
  domain basis.

Is AppDomain equivalent to a Process for .NET code?

An AppDomain does not provide the same degree of isolation as a process does. In fact if you're worried that the 3rd party component is not in good shape there's a risk, that it will take down your .NET application.

An AppDomain cannot be unloaded if unmanaged code is executing at the time of unload, so you may have a hard time controlling your 3rd party code in an AppDomain. See http://msdn.microsoft.com/en-us/library/system.appdomain.unload.aspx

Even for managed code only, an AppDomain does not provide a robust sandbox solution. E.g. if the loaded code spawns any threads these will take down the entire process in case of unhandled exceptions. This question has a bit more info: .NET - What's the best way to implement a "catch all exceptions handler".

As far as I am aware the best option for hosting code like that in a .NET application is to implement your own CLR host process like IIS and SQL Server does.

Using AppDomain in C# to dynamically load and unload dll

Thanks guys, here is link where i found answer to my quetion:

The MSDN forum description for load and unload of assemblies dynamically

The other dll can be dynamically loaded and unloaded using another class which does load assembly and and call methods in that assembly...
AppDomain.CreateInstanceAndUnwrap generally wants input as assemblies from current project or generally current namespace. to solve that i need Assembly.LoadFrom(); to be used in some other class and create AppDomain and create instance of this class using AppDomain object as given in link.

Thanks for ur replies guys.

What's the difference between Application and AppDomain.CurrentDomain

They have nothing in common, really.

Application is a class specific to Windows Forms, a .NET GUI technology. The Application.StartupPath is handled by the Kernel32 function GetModuleFileName. Through not passing a pointer to a module, the main module's path is returned - that is the exe file, basically.

AppDomain is a core .NET concept for domain isolation. Basically, it allows you to isolate (imperfectly of course) multiple applications in a single native process. Most applications only have a single AppDomain, but you can create as many as you like. The base path of an application domain is handled by Fusion, a .NET assembly loading technology. A very typical example would be ASP.NET applications hosted in IIS - each application has its own AppDomain, but they're all hosted in a single native process ("application pool"). Each logical application can be restarted without touching the others, and they don't have (simple) access to each other, but a process-tearing exception (e.g. StackOverflowException) will still kill the whole pool.

Another interesting class that's somewhat related is Environment. You can use Environment.CommandLine to get the process command line (which includes the path to the executable, including the name of the executable). This is basically a communication interface between the CLR and the underlying system - in this case, it takes care of saving the arguments for the application (which are passed by the OS to the Main function) and making them available at any time in the future.

Environment.CommandLine is somewhat clunky to parse (it's the raw command-line, basically - I assume it will have different conventions on Windows than on Linux, for example), but it's the only way you can always get to the executable. Again, Application.StartupPath is Winforms specific, and you can have more than one AppDomain - and possibly, the AppDomain might not even have a reasonable BaseDirectory.

The .NET Reflection APIs also give you a few ways. For example, Assembly.GetEntryAssembly() will give you the executable assembly - however, this only works for the main AppDomain - other domains will have their own entry assemblies (in fact, they'll usually just return null :)). You can get the path to an assembly through the Assembly.CodeBase property, but do note that this might not always be what you expect. You can also use Assembly.Location, or get the FullyQualifiedName of any of the assembly's modules (again, most assemblies only have a single module; and again, ASP.NET is one of the prime examples of when this isn't the case).

---

Related Topics