Managed and Unmanaged code in Dot Net

Managed Code:
The .NET Framework provides a run-time environment called the Common Language Runtime, which manages the execution of code and provides services that make the development process easier. Compilers and tools expose the runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.

The managed execution process includes the following steps:

1. Choosing a compiler.
2. To obtain the benefits provided by the common language runtime, you must use one or more language compilers that target the runtime.
3. Compiling your code to Microsoft intermediate language (MSIL).
4. Compiling translates your source code into MSIL and generates the required metadata.
5. Compiling MSIL to native code.
6. At execution time, a just-in-time (JIT) compiler translates the MSIL into native code. During this compilation, code must pass a verification process that examines the MSIL and metadata to find out whether the code can be determined to be type safe.
7. Executing your code.

The common language runtime provides the infrastructure that enables execution to take place as well as a variety of services that can be used during execution.

Unmanaged Code:
The code, which is developed outside .NET, Framework is known as unmanaged code.
Applications that do not run under the control of the CLR are said to be unmanaged, and certain languages such as C++ can be used to write such applications, which, for example, access low - level functions of the operating system. Background compatibility with code of VB, ASP and COM are examples of unmanaged code.
Unmanaged code can be unmanaged source code and unmanaged compile code.
Unmanaged code is executed with help of wrapper classes.

Wrapper classes are of two types:

• CCW (COM Callable Wrapper)
• RCW (Runtime Callable Wrapper)

Wrapper is used to cover difference with the help of CCW and RCW.
COM callable wrapper unmanaged code execution

(COM)

What is Interop Services?
The common language runtime provides two mechanisms for interoperating with unmanaged code:

Platform invoke, which enables managed code to call functions exported from an unmanaged library.
COM interop, which enables managed code to interact with COM objects through interfaces.

Both platform invoke and COM interop use interop marshaling to accurately move method arguments between caller and callee and back, if required.


RCW (Runtime Callable Wrappers)
The common language runtime exposes COM objects through a proxy called the runtime callable wrapper (RCW). Although the RCW appears to be an ordinary object to .NET clients, its primary function is to marshal calls between a .NET client and a COM object.

CCW (COM Callable Wrapper)

A proxy object generated by the common language runtime so that existing COM applications can use managed classes, including .NET Framework classes, transparently.

Pinvoke:
Platform invoke is a service that enables managed code to call unmanaged functions implemented in dynamic-link libraries (DLLs), such as those in the Win32 API. It locates and invokes an exported function and marshals its arguments (integers, strings, arrays, structures, and so on) across the interoperation boundary as needed.
Is it true that COM objects no longer need to be registered on the server?
Answer: Yes and No. Legacy COM objects still need to be registered on the server before they can be used. COM developed using the new .NET Framework will not need to be registered. Developers will be able to auto-register these objects just by placing them in the 'bin' folder of the application.

Can .NET Framework components use the features of Component Services?
Answer: Yes, you can use the features and functions of Component Services from a .NET Framework component.
http://msdn.microsoft.com/library/techart/Pahlcompserv.htm

Reflection in .Net

All .NET compilers produce metadata about the types defined in the modules they produce. This metadata is packaged along with the module (modules in turn are packaged together in assemblies), and can be accessed by a mechanism called reflection.
The System.Reflection namespace contains classes that can be used to interrogate the types for a module/assembly.
Using reflection to access .NET metadata is very similar to using ITypeLib/ITypeInfo to access type library data in COM, and it is used for similar purposes - e.g. determining data type sizes for marshaling data across context/process/machine boundaries.
Reflection can also be used to dynamically invoke methods (see System.Type.InvokeMember), or even create types dynamically at run-time (see System.Reflection.Emit.TypeBuilder).

Serialization in .NET

Serialization is the process of converting an object into a stream of bytes.
Deserialization is the opposite process of creating an object from a stream of bytes. Serialization/Deserialization is mostly used to transport objects (e.g. during remoting), or to persist objects (e.g. to a file or database).
Serialization can be defined as the process of storing the state of an object to a storage medium. During this process, the public and private fields of the object and the name of the class, including the assembly containing the class, are converted to a stream of bytes, which is then written to a data stream. When the object is subsequently deserialized, an exact clone of the original object is created.

Binary serialization preserves type fidelity, which is useful for preserving the state of an object between different invocations of an application. For example, you can share an object between different applications by serializing it to the clipboard. You can serialize an object to a stream, disk, memory, over the network, and so forth. Remoting uses serialization to pass objects "by value" from one computer or application domain to another.
XML serialization serializes only public properties and fields and does not preserve type fidelity. This is useful when you want to provide or consume data without restricting the application that uses the data. Because XML is an open standard, it is an attractive choice for sharing data across the Web.
SOAP is an open standard, which makes it an attractive choice.

There are two separate mechanisms provided by the .NET class library -
XmlSerializer and SoapFormatter/BinaryFormatter. 
Microsoft uses XmlSerializer for Web Services,
Soap Formatter/Binary Formatter for remoting. Both are available for use in your own code.

Why do I get errors when I try to serialize a Hashtable?
XmlSerializer will refuse to serialize instances of any class that implements IDictionary, e.g. Hashtable. SoapFormatter and BinaryFormatter do not have this restriction.

Application Domain in .Net

Application Domain in .Net
The primary purpose of the AppDomain is to isolate an application from other applications.
Win32 processes provide isolation by having distinct memory address spaces. This is effective, but it is expensive and doesn't scale well. The .NET runtime enforces AppDomain isolation by keeping control over the use of memory - all memory in the AppDomain is managed by the .NET runtime,
so the runtime can ensure that AppDomains do not access each other's memory.
Objects in different application domains communicate either by transporting copies of objects across application domain boundaries, or by using a proxy to exchange messages.
MarshalByRefObject is the base class for objects that communicate across application domain boundaries by exchanging messages using a proxy. Objects that do not inherit from MarshalByRefObject are implicitly marshal by value. When a remote application references a marshal by value object, a copy of the object is passed across application domain boundaries.


How does an AppDomain get created?
AppDomains are usually created by hosts.
Examples of hosts are the Windows Shell, ASP.NET and IE. When you run a .NET application from the command-line, the host is the Shell.
The Shell creates a new AppDomain for every application.
AppDomains can also be explicitly created by .NET applications. Here is a C# sample which creates an AppDomain, creates an instance of an object inside it, and then executes one of the object's methods. Note that you must name the executable 'appdomaintest.exe' for this code to work as-is.

Diffrence between Object pooling and Connection pooling

Object pooling is a COM+ service that enables you to reduce the overhead of creating each object from scratch. When an object is activated, it is pulled from the pool. When the object is deactivated, it is placed back into the pool to await the next request.
You can configure object pooling by applying the ObjectPoolingAttribute attribute to a class that derives from the System.EnterpriseServices.ServicedComponent class.
Object pooling lets you control the number of connections you use, as opposed to connection pooling, where you control the maximum number reached.

Following are important differences between object pooling and connection pooling:

Creation. When using connection pooling, creation is on the same thread, so if there is nothing in the pool, a connection is created on your behalf. With object pooling, the pool might decide to create a new object. However, if you have already reached your maximum, it instead gives you the next available object. This is crucial behavior when it takes a long time to create an object, but you do not use it for very long.
Enforcement of minimums and maximums. This is not done in connection pooling.
The maximum value in object pooling is very important when trying to scale your application. You might need to multiplex thousands of requests to just a few objects. (TPC/C benchmarks rely on this.)

COM+ object pooling is identical to what is used in .NET Framework managed SQL Client connection pooling. For example, creation is on a different thread and minimums and maximums are enforced.