Migration and Interoperability Portal
The topics in this section discuss the Windows Software Development Kit (SDK) managed programming model and how it can be used for migration and interoperation with your unmanaged applications.
Code executing under the control of the common language runtime (CLR) is called managed code. Conversely, code that runs outside the runtime is called unmanaged code. Windows SDK API functions are examples of unmanaged code.
The Windows SDK provides a rich environment for creating applications by using managed or unmanaged code. Although it is possible to develop complete solutions in either environment, there are situations in which you will want to combine the features of both managed and unmanaged programming models in your applications.
If you have existing unmanaged components, you can access these components from managed code.
If you have existing managed components, you can access these components from unmanaged code.
You can access components that are available only from the unmanaged programming model in your managed applications. For example, you can add Search and Organize tasks to your WPF-based applications.
You can access components available only from the Windows SDK in your unmanaged applications. For example, you can host a WPF page in an unmanaged page.
Windows SDK and Managed Code Interoperability
In many cases, the API for a feature is distributed only in a managed or unmanaged programming model. For example, many of the shell extensions are found only in Win32, which is the unmanaged programming model for the Windows operating system. Many of the communication features are found only in Microsoft .NET Framework, which is the managed programming model for Windows Vista.
Accessing Windows SDK Components from Managed Code
The Microsoft .NET Framework promotes interaction with the Windows SDK. Data types, method signatures, and error-handling mechanisms vary between managed and unmanaged object models. To simplify interoperation between .NET Framework components and unmanaged code and to ease the migration path, the CLR conceals the differences in these object models from both clients and servers.
Calling unmanaged DLL functions using Platform Invoke
Platform Invoke (P/Invoke) is a service that enables managed code to call unmanaged functions that are implemented in dynamic link libraries (DLLs) provided in the Windows SDK. P/Invoke locates and invokes an exported function and marshals (moves) its arguments (integers, strings, arrays, structures, and so on) across the interoperation (managed/unmanaged) boundary as needed.
To call unmanaged DLL functions using P/Invoke, follow these basic steps:
Identify the functions in the DLLs. At a minimum, you must know the name of the function and name of the DLL that contains it.
Create a prototype for the function in managed code.
Call the function defined by the prototype.
Interacting with unmanaged code through interfaces
Component Object Model (COM) interoperation enables managed code to interact with COM objects through interfaces. The basic steps are as follows:
Import a type library as an assembly. Object model type definitions usually reside in a type library. In contrast, managed code compilers produce type metadata in an assembly. The two sources of type information are different. Both Visual Studio 2005 (which can automatically convert COM types) and the .NET Framework SDK (which includes the tblimp.exe command-line tool) provide tools to generate metadata from a type library. The resulting assembly is called an interop assembly. A reference to the library is added during compilation.
Create COM types in managed code. You can inspect COM types, activate instances, and invoke methods on the COM object the same way you do for any managed type.
Compile the project.
Deploy the application. Interop applications are best deployed as strong-named, signed assemblies in the global assembly cache.
Accessing .NET Framework 3.0 components from unmanaged code
You can access managed components in unmanaged applications by using C++/CLI. C++/CLI is the successor to Managed Extensions for C++. It uses the new language extensions for managed code and the /crl compiler switch for Microsoft C++. The /clr switch creates metadata for the application that can be consumed by other managed applications, and enables the application to consume types and data in the metadata of other managed components. The /clr switch can be applied to an entire project or only to the modules that reference Microsoft .NET Framework objects.
For example, you can migrate an existing application that consists entirely of unmanaged functions to the .NET platform by recompiling just one module with the /clr compiler switch. This module is then able to use .NET features, but remains compatible with the remainder of the application. This method enables you to convert an application to the .NET platform in a gradual, piece-by-piece way. You can even decide between managed and unmanaged code compilation on a function-by-function basis within the same file.
Considerations in Interoperability
While interoperability can be simple to implement, the following concepts will affect the performance, execution, and security of your applications:
Marshaling: The interop marshaler marshals data between the CLR heap and the unmanaged heap. Marshaling occurs whenever the caller and callee cannot operate on the same instance of data. The interop marshaler makes it possible for both the caller and callee to appear to be operating on the same data although they each have their own copy of the data. Different techniques are used to marshal different data types, such as strings, structures, classes, and arrays.
Performance: Regardless of the interoperability technique used, special transition sequences, called thunks, are required each time a managed function calls an unmanaged function and vice versa. The Microsoft Visual C++ compiler inserts these thunks automatically. Cumulatively, these transitions can be expensive in terms of performance. The number of transitions and the interoperability technique used (P/Invoke or COM) affect the application’s performance.
Code access security: Applications that use unmanaged code are subject to code access security limitations on native code. Compiler options are available to remove these dependencies, if you determine that this is a secure choice.
Threading models: COM also has a marshaler that marshals data between COM apartments or different COM processes. When calling between managed and unmanaged code within the same COM apartment, the interop marshaler is the only marshaler involved. Calling between managed code and unmanaged code in different COM apartments or different processes involve both the interop marshaler and the COM marshaler.
See Also
Concepts
Migration and Interoperability Roadmap