The big difference is that the isolation offered by AppDomains relies entirely on the type safety of verifiable code. That's fine if you're running just verifiable managed code. But if your application contains a mixture of managed and unmanaged code, or (more unusually) if it contains unverifiable managed code, AppDomains don't offer real isolation.
For example, if you load a COM component from .NET, that COM component isn't isolated to the AppDomain, because COM doesn't recognize AppDomains, and is not bound by them. Processes on the other hand are an operating system feature. The OS uses the memory management hardware built into the CPU to enforce isolation. So even unmanaged code and unverifiable code cannot break through the isolation offered by a process. So if you need isolation of unmanaged code, or of unverifiable managed code, you need a full process boundary to enforce that isolation. The price of this is that a process is much more expensive. An OS process uses more resources, so you can have fewer of them. It's also more expensive to switch between them. There's another difference. An OS process runs under a particular security principal, and this determines what things code running in that process is allowed to do. And while it's possible to arrange for a thread to 'impersonate' another principal, there are a number of limitations with that. Sometimes you will need a process to be running as a particular principal. And unless you happen to need all your Appdomains running as that principal, that might be a reason to use multiple processes. In general, the costs of processes means you would typically prefer multiple AppDomains over multiple processes unless you have a specific requirement that means you need multiple processes. However, it really depends on the scenario. Processes aren't all that expensive. If you're running a server-side app on a dedicated box, the cost of, say, 4 or 5 processes won't be a big deal, and even as many as 20 might be bearable. On the other hand, if you're running an application on an end-user machine, resources are likely to be more tight, and adding a load of extra processes to a desktop is an antisocial thing for an application to do, so it's best avoided unless you really need multiple processes. -- Ian Griffiths http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: Muhammad Adel > > Hello > I have a question that may seem basic, but I couldn't find an answer for > it. > What are the situations in which I need to use multiple processes > instead of multiple application domains in one process? > thanks for your help =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
