MSDN Magazine - January 2009 - (Page 16)

Creating Signatures in P/Invoke Interop Assistant to use, however, if the unmanaged APIs have a lot of arguments that don’t have good managed equivalents such as variable-length structures, void *s, overlapping unions, and so on. The .NET Framework base class libraries (BCLs) contain many examples of APIs that are really just thick wrappers around large numbers of P/Invoke declarations. Nearly all functionality in the .NET Framework that wraps unmanaged Windows APIs is built using P/Invoke. In fact, even Windows Forms is built almost entirely on the native ComCtl32.dll using P/Invoke. There are a few very valuable resources that can make using P/Invoke significantly easier. First, the Web site pinvoke.net has a wiki, originally set up by Adam Nathan from the CLR interop team, that has a large number of user-contributed signatures for a wide variety of common Windows APIs. There is also a very handy Visual Studio add-in that makes it easy to consult pinvoke.net from within Visual Studio. For APIs that are not covered on pinvoke.net, whether they are from your own libraries or someone else’s, the interop team has released a P/Invoke signaturegenerating tool called the P/Invoke Interop Assistant (codeplex.com/ clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120), which automatically creates signatures for native APIs based on a header file. The accompanying screenshot shows the tool in action. COM interop is less useful if your application does not already use COM internally, or if you don’t need full fidelity COM semantics and its performance is not acceptable for your application. Microsoft Office is the most prominent example of an application that uses COM interop as its bridge between managed and native code. Office was a great candidate for COM interop, as it has long used COM as its extensibility mechanism and was most commonly used from Visual Basic for Applications (VBA) or Visual Basic 6.0. Originally Office relied entirely on TlbImp and the thin interop assembly as its managed object model. Over time, however, the Visual Studio Tools for Office (VSTO) product was built into Visual Studio, providing a richer and richer development model that incorporated many of the principles described in this column. When using the VSTO product today, it is sometimes as easy to forget that COM interop is serving as the foundation of VSTO as it is to forget that P/Invoke is the foundation of much of the BCLs. Interop Technologies: C++/CLI Interop Technologies: COM Interop COM interop allows you either to consume COM interfaces from managed code or expose managed APIs as COM interfaces. You can use the TlbImp tool to generate a managed library that exposes managed interfaces for talking to a specific COM tlb. And TlbExp performs the opposite task and will generate a COM tlb with interfaces that correspond to the ComVisible types in a managed assembly. COM interop can be a very good solution for you if you are already using COM inside your application or as its extensibility model. It is also the easiest way to maintain full-fidelity COM semantics between managed and native code. In particular, COM interop is an excellent choice if you are interoperating with a Visual Basic 6.0-based component, as the CLR follows basically the same COM rules Visual Basic 6.0 does. 16 msdn magazine C++/CLI is designed to be a bridge between the native and managed world, and it allows you to compile both managed and native C++ into the same assembly (even the same class) and make standard C++ calls between the two portions of the assembly. When you use C++/CLI, you choose which portion of the assembly you want to be managed and which you want to be native. The resulting assembly is a mix of MSIL (Microsoft intermediate language, found in all managed assemblies) and native assembly code. C++/CLI is a very powerful interop technology that gives you almost complete control over the interop boundary. The downside is that it forces you to take almost complete control over the boundary. C++/CLI can be a good bridge if static-type checking is needed, if strict performance is a requirement, and if you need more predictable finalization. If P/Invoke or COM interop meets your needs, they are generally simpler to use, especially if your developers are not familiar with C++. There are a few things to keep in mind when considering C++/ CLI. The first thing to remember is that if you are planning to use C++/CLI to provide a faster version of COM interop, COM interop is slower than C++/CLI because it does a lot of work on your behalf. If you only loosely use COM in your application and don’t require full fidelity COM interop, then this is a good trade-off. If, however, you use a large portion of the COM spec, you’ll likely find that once you add back the pieces of COM semantics you need into your C++/CLI solution, you’ll have done a lot of work and will have performance no better than what is provided with COM interop. Several Microsoft teams have gone down this road only to realize this and move back to COM interop. The second major consideration for using C++/CLI is to remember that this is only intended to be a bridge between the managed and native worlds and not intended to be a technology you use to ClR Inside Out http://www.pinvoke.net http://www.pinvoke.net http://www.pinvoke.net http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?Released=14120 http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?Released=14120

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.