MSDN Magazine - January 2009 - (Page 15)

Jesse KAPlAN CLR InsIde Out Best Practices For Managed And Native Code Interoperability In some ways, it may seem odd to see a column like this one appearing in MSDN Magazine in early 2009—managed and native code interoperability has been supported in the Microsoft .NET Framework, in more or less the same form, since version 1.0 in 2002. In addition, you can readily find detailed API- and tool-level docs and thousands of pages of detailed support documents. Yet the missing piece in all of this is comprehensive, high-level architectural guidance describing when to use interop, what architectural considerations you should take into account, and which interop technology to use. This is the gap I’m going to begin to fill here. Interop is going to allow developers to maintain their existing investment in native code. When Is Managed-Native Interop Appropriate? There has not been a great deal written about when it’s appropriate to use managed-native interop, and much of what can be found on the subject is conflicting. Sometimes the guidance is not based on actual practical experience, either. So before I begin, let me state that everything I’m writing about today is guidance that we developed based on the experiences the interop team has had helping internal and external customers of all sizes. In synthesizing this experience, we put together three products that serve as excellent examples of successful uses of interop and a representative set of the types of uses of interop. Visual Studio Tools for Office is the managed extensibility toolset for Office and is the first application I think of when I think of interop. It represents the classic use of interop—a large native application that wants to enable managed extensions or add-ins. Next on my list is Windows Media Center, an application that was built from the ground up as a mixed managed and native application. Windows Media Center was developed using mostly managed code with some portions—those dealing directly with the TV tuner and other hardware drivers—built in native code. Finally there is Expression Design, an application with a large, preexisting native code base that wants to leverage new managed technologies, in this case Windows Presentation Foundation (WPF), to provide a next-generation user experience. These three applications address the three most common reasons to use interop: to allow managed extensibility of preexisting native applications, to allow most of an application to take advantage of the benefits of managed code while still writing the lowest-level pieces in native code, and to add a differentiated, next-generation user experience to an existing native application. In the past, available guidance would have suggested simply rewriting the entire application in managed code in these instances. Trying to follow this advice and seeing how many people simply refuse to follow it has made it clear that this simply isn’t an option for most existing applications. Interop is going to be the vital technology that allows developers to maintain their existing investment in native code while still being able to take advantage of the new managed environment. If you are planning to rewrite your application for other reasons, managed code may be a good choice for you. But you generally don’t want to rewrite your application merely to use new managed technologies and avoid interop. Interop Technologies: Three Choices There are three main interop technologies available in the .NET Framework, and which one you choose will be determined in part by the type of API you are using for interop and in part by your requirements and need to control the boundary. Platform Invoke, or P/Invoke, is primarily a managed-to-native interop technology that allows you to call C-style native APIs from managed code. COM interop is a technology that allows you either to consume native COM interfaces from managed code or export native COM interfaces from managed APIs. Finally there is C++/CLI (formerly known as managed C++), which allows you to create assemblies that contain a mix of managed and native C++ compiled code and is designed to serve as a bridge between managed and native code. Interop Technologies: P/Invoke P/Invoke is the simplest of the three technologies, and it was designed primarily for providing managed access to C-style APIs. With P/Invoke you need to wrap each API individually. This can be a very good choice if you have a few APIs to wrap and their signatures are not very complex. P/Invoke gets substantially harder Send your questions and comments to clrinout@microsoft.com. January 2009 15

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.