How do in-process and cross-process communication work in the Common Language Runtime?

Submitted by: Administrator
There are two aspects to in-process communication: between contexts within a single application domain, or across application domains. Between contexts in the same application domain, proxies are used as an interception mechanism. No marshaling/serialization is involved. When crossing application domains, we do marshaling/serialization using the runtime binary protocol.
Cross-process communication uses a pluggable channel and formatter protocol, each suited to a specific purpose.
If the developer specifies an endpoint using the tool soapsuds.exe to generate a metadata proxy, HTTP channel with SOAP formatter is the default.
If a developer is doing explicit remoting in the managed world, it is necessary to be explicit about What channel and formatter to use. This may be expressed administratively, through configuration files, or with API calls to load specific channels. Options are:
HTTP channel w/ SOAP formatter (HTTP works well on the Internet, or anytime traffic must travel through firewalls)
TCP channel w/ binary formatter (TCP is a higher performance option for local-area networks (LANs))
When making transitions between managed and unmanaged code, the COM infrastructure (specifically, DCOM) is used for remoting. In interim releases of the CLR, this applies also to serviced components (components that use COM+ services). Upon final release, it should be possible to configure any removable component.
Distributed garbage collection of objects is managed by a system called "le
Submitted by: Administrator

Read Online ASP Programming Job Interview Questions And Answers