1) What is Application Domain?

A Common Language Runtime application domain is a mechanism (similar to an opera ting system process), used to isolate executed software applications from one an other so that they do not affect each other. This is achieved by making any uniq ue virtual address space run exactly one application and scopes the resources fo r the process or application domain using that address space. A Common Language Runtime (CLR) application domain is contained within an operat ing system process. A process may contain many application domains. This carries major advantages: There is lower system cost. Multiple threads can exist within a single AppDomain. The application in a domain can be stopped without affecting the state of anothe r domain in the same process. A fault or exception in one domain does not affect an application in another dom ain or crash the entire process that hosts the domains. Configuration information is part of a domain's scope, not the scope of the proc ess. Each domain can be assigned different security access levels, all within a singl e process. Code in one domain cannot directly access code in another (see below). In this sense, the CLR is like a mini-operating system. It runs a single process that contains a number of sub-process, or application domains. Direct communication cannot be achieved across application domains. However, app lication domains can still talk to each other by passing objects via marshaling by value (unbound objects), marshaling by reference through a proxy (AppDomain-b ound objects). There is a third type of object called a context-bound object whi ch can be marshalled by reference across domains and also within the context of its own application domain. Because of the verifiable type-safety of managed cod e, the CLR can provide fault isolation between domains at a much lower cost than an operating system process can. The static type verification used for isolatio n does not require the same process switches or hardware ring transitions that a n operating system process requires. 2)what is marshalling by value? A) MBV consists in constructing a clone to remote object,in the same App domain as the client.The CLR makes it so that the clone has excatly the same state as t he remote object.Let us precise that the state of an object at a specific point in time is the set of the value type fields of the object. Depending on the applica tion the state of the object also contains the state taken by the objects referenced by the ref erenced type fields of the object. The clone is not a remote object.The client does not require a transperent proxy to access it.Note that no constructor is called on the clone.This behaviour is logical since the clone must be excatly as the orginal object on which a constru ctor has been called. 3)what is marshall by reference? A)Marshal-by-reference Objects Marshal-by-reference objects are remotable objects that extend the System.Marsha lByRefObject class. When a client instantiates a marshal-by-reference object, th e .NET Remoting infrastructure creates a proxy object in the caller's applicatio n domain and returns a reference to that proxy to the caller. When the client ma kes calls on that object through the proxy, the Remoting infrastructure marshals the calls, sends them to the originator's application domain, and invokes the c all on the actual object. Function return values and out parameters are handled

similarly on the way back. You should use marshal-by-reference objects when the state of the object and any executable functionality must remain in the application domain in which it was created (that is, on the server). Scope of publication .NET Remoting exposes objects to other application domains as if they are local, with a few exceptions. The two exceptions most likely to trip you up are: Static members are never remoted. Remoting always deals with some form of object instance member. Private methods are never remoted. You cannot wrap and pass a delegate to a priv ate method. This includes remote event handlers. The other exceptions are less likely to cause you trouble. The online documentat ion provides a complete list and explanation of the exceptions. Proxies In the general sense, a proxy is any object that stands in for another, either s ervicing requests directly or passing the requests on to the object for which it is standing in. In .NET Remoting, the proxy manages the marshaling process and the other tasks required to make cross-boundary calls. The .NET Remoting infrast ructure automatically handles creation and management of proxies, although it is possible to create your own proxy classes to plug in to and customize proxy cre ation, marshaling, and other proxy-related tasks.