Managed Code and Unmanaged Code related ASP.NET Interview Questions

What is Managed Code and Unmanaged Code?
Microsoft ASP.NET Web applications run under the control of the common language runtime (CLR). The CLR controls how the application’s assembly executes, allocates, and recovers memory; therefore, ASP.NET applications are said to use managed code. In contrast, most other Windows executables use unmanaged code because the executable itself determines how memory is used.

Examples of unmanaged code include the Microsoft Win32 API, legacy DLLs and EXEs created for Windows applications prior to the Microsoft .NET Framework, and COM objects.

What is Platform Invoke or pinvoke?
The process of executing native code from within a .NET assembly is called platform invoke, or pinvoke for short. You use platform invoke to call the Win32 API directly, to access existing (legacy) DLLs your company uses, or to access procedures compiled to native code for performance reasons.

What are the steps to follow to use Platform Invoke?
To use platform invoke, follow the following steps:
1. Import the System.Runtime.InteropServices namespace.
2. Declare the unmanaged procedure using the DllImport attribute or the Declare statement.
3. Map the data types of the procedures parameters to the equivalent .NET types.
4. Call the unmanaged procedure and test its return value for success.
5. If the procedure did not succeed, retrieve and handle the exception code using the Marshal object’s GetLastWin32Error method.

What are the limitations of using Unmanaged Code from within a .NET assembly?
Performance : Although native-code DLLs can perform some operations more quickly than equivalent code managed by the CLR, these benefits might be offset by the time it takes to marshal the data to pass between the unmanaged procedure and the .NET assembly.
Type safety : Unlike .NET assemblies, unmanaged procedures might not be type-safe. This can affect the reliability of your .NET application. In general, reliability is a paramount concern with ASP.NET Web applications.
Code security : Unmanaged procedures do not use the .NET Framework’s model for code security.
Versioning:Unmanaged code does not support .NET versioning; therefore, assemblies that call unmanaged procedures might lose the benefit of being able to coexist with other versions of the same assembly.

What are COM objects?
COM objects are another type of unmanaged code that you can use from .NET assemblies. Because COM is widely used, Visual Studio includes built-in tools for importing and using COM objects within .NET assemblies. Visual Studio also includes the option of automatically registering .NET class library assemblies for use from COM.

List the steps in order, to use a COM object from a .NET assembly in Visual Studio?
1. Install and register the COM object on your system.
2. Open the .NET project in Visual Studio, and add a reference to the COM object, as shown in diagram below. If the COM object does not appear on the COM tab of the Add Reference dialog box, you can add a reference directly to the executable by clicking Browse.

3. Create an instance of the COM object in code, and use it as you would any other object.

What happens when you add a reference to a COM object from with in a dot net application?
When you add a reference to a COM object, Visual Studio automatically generates an interop assembly for the object and places it in the project’s /bin folder. The interop assembly is created from the COM object’s type information and contains the metadata that the CLR uses to call the unmanaged code in the COM object. You can then use COM objects from within .NET code the same way that you use .NET classes.

You can view this interop assembly using the Microsoft Intermediate Language Disassembler (Ildasm.exe) included in the .NET Framework.

Can we create a .NET object for use from COM?
Yes, Visual Studio can automatically generate type library information and register a .NET class library assembly for use from COM. These automatic tools do not work for ASP.NET Web applications, so you must isolate the code you want to use from COM in its own Class Library project.

How do you hide Public .NET Classes and other public members from COM?
In some cases, you might want to hide selected .NET classes from COM but keep them public for use from other .NET assemblies. The ComVisible attribute allows you to select which public .NET classes and members are included in the generated type library. This attribute applies hierarchically for the assembly, class, and member levels.
How do you handle exceptions between .NET and COM?
.NET handles errors through exception classes. COM handles errors through 32-bit data types called HRESULTs. All of the .NET exception classes include HResult properties that map to COM HRESULT codes.

If an exception occurs in a .NET object, the exception is automatically mapped to the appropriate HRESULT and returned to COM. Similarly, if an exception occurs in a COM object, the COM HRESULT is mapped to the appropriate exception class, which is returned to .NET, where it can be handled just like any other exception.

If you are creating your own .NET exception classes for use with COM, be sure to set the class’s HResult property so that the exception can be handled within COM.

What are the technical limitations of COM Interop?
The .NET Framework was developed to address the limitations of COM. Because of this evolution, there are limits to the .NET features that you can use from COM. The following list describes these limits:
Static members : COM requires objects to be created before use, so it does not support .NET Static members.
New members : COM flattens the inheritance tree of .NET objects, so members in a derived class that hides members inherited from a base class are not callable.
Constructors with parameters : COM can’t pass parameters to an object’s constructor.

What are the practical limitations of using COM objects?
The following are the practical limitations of using COM objects from .NET:
Shared solutions might not allow COM objects : ASP.NET host service providers that use nondedicated servers can limit or prohibit the installation of COM objects on their servers.
COM objects are prone to memory leaks : COM uses reference counting to determine when to destroy objects and free memory. It is possible for this reference count to become incorrect, leaving objects in memory indefinitely.
Type libraries might be inaccurate : Because COM separates the object’s description from its implementation, it’s possible for this description to not accurately reflect the object. In this case, the generated interop assembly will also include those inaccuracies.
COM is unmanaged code : All the limitations of unmanaged code apply to COM objects as well.