For next few days I intend to write about various aspects of .Net Interops and different scenarios where Interops are extremely useful.
Before moving ahead to interops lets first check out some of the important terminologies in .NET .
Managed Code and Data :
Code developed on .NET platform (e.g. code in C#,VB.NET etc) is referred to as managed code and contains some metadata which is used for Common Language Runtime. ( for more info visit CLR Team Blog ) Data used by .NET applications is called managed data , since .NET runtime manages data-related tasks such as allocating and reclaiming memory, and type checking. By default code and data used by .NET applications is managed and while accessing the unmanaged code and data e.g. COM objects we can use interop assemblies which will be discussed in later part of this post.
A primary building block of .NET application is referred to as assembly. It is a collection of functionality that is built, versioned and deployed as a single implementation unit containing one or more files. Each assembly contains a assembly manifest. Every assembly whether static or dynamic contains collection of data that describes how the elements in the assembly relate to each other. The metadata contained in assembly is needed to specify the assembly’s version requirements and security identity. The assembly manifest can be stored in either a PE file ( an .exe or .dll ) with Microsoft intermediate language (MSIL) code or in a standalone PE file that contains only assembly manifest information. ( A must see article on assemblies is here MSDN )
Type Libraries and Assembly Manifests :
A type library declares the classes , interfaces , constants and procedures that are exposed by an application or dynamic link library ( DLL ) . A type library is usually a resource in a program file. It can also be a stand-alone binary file with the extension .tlb or .olb . Manifests also include information about
- Assembly identity, version, culture and digital signature
- Files that make up the assembly implementation
- Types and resources that make up the assembly, including those
- that are exported from it
- Compile-time dependencies on other assemblies.
- Permissions required to run the assemblies to run properly.
For importing information from a type library into .NET application Visual Studio.NET contains a utility called as Tlbimp.exe. ( more information is given here. )
Why Interops ?
While implementing solutions for various problem statements there is a necessity of invoking features provided by other applications or interaction with APIs provided to invoke important services or features.
Following may be some of the scenarios where interops are required
- Invoking Win32 apps in .NET
- Invoking COM components in application.
- Invoking features of MS Office.
- Invoking inter language communication
- Invoking features of .NET on other platforms.
- Invoking functionality provided by a native code where a conversion process is necessary to translate argument data between managed code and native code.
Ways to implement Interops :
Having seen some of the basic reasons why interoperability is required , lets see some of the ways these interops can be implemented.
Primary Interop Assembly is a unique, vendor supplied assembly that contains type definitions ( as metadata) of types implemented with COM. There can be only one Primary Interop Assembly , which must be signed with a strong name by the publisher of COM type library. A single primary interop assembly can wrap more than one version of the same type library.
Primary Interop Assemblies must meet following requirements
- Include all COM types defined in the original type library and maintain the same GUID identities.
- Be signed with a strong name using standard public key cryptography
- Contain the PrimaryInteropAssemblyAttribute.
- Avoid redefining external COM types.
- Reference other primary interop assemblies for external for external COM dependencies.
Having a single type definition ensures that all .NET framework applications bind to the same type at compile time, and that the type is marshaled the same way at run time. It is important to create only one primary interop assembly for each COM type library because multiple assemblies can introduce type incompatibility.
There are several other aspects with PIA such as
- Naming a primary interop assembly
- Generating a primary interop assembly
- Customizing a primary interop assembly
- Distributing a primary interop assembly
MSDN explains in-depth approach of all these points.
Office XP PIAs can be downloaded here .
System.Runtime.InteropServices namespace provide a wide variety of members that support COM interop and platform invoke services.
A detailed description of its classes and structures is given on MSDN which covers all the aspects about using this namespace and is a must read chapter for everyone who wants to cover this concepts in a systematic approach.
Platform Invoke services ( commonly referred as P/Invoke) allows managed code to call unmanaged functions that are implemented in a DLL.
Important aspects one must consider while using P/Invoke are
- Using Attributes
- DllImportAttribute Class
- MarshalAsAttribute Class
- StructLayoutAttribute Class
- InAttribute Class
- OutAttribute Class
Java and .NET interoperability
With Restlet lightweight open source project its now possible to use lightweight REST framework for Java that used Restlet extension for ADO.NET Data Services.
More info about Restlet open source project is here
In coming articles I will be explaining all of these ways in detail and resources that one must have a look for covering several effective practices while using Interops. I will also be covering various areas where these interops can be used.
Do let me know all of your suggestions and areas to be covered in this post.
Keep Visiting !!