Programming with Managed Extensions for Microsoft® Visual C++® .NET

Author Richard Grimes Pages 564 Disk N/A Level All Levels Published 07/31/2002 ISBN 9780735617247 Price $49.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Companion Content Related Series Related Books About the Author Support: Book & CD Rate this book

Chapter 2: Interop

• It Just Works!
• Native C++ Classes
• CRT and Static-Link Libraries
• C++ Standard Library
• Managed Pointers in Unmanaged Types
• Global Methods

2  Interop

Native code runs outside of the control of the .NET runtime, so when you make calls to native code, you have to take into account that pointers are not tracked, memory is not garbage collected, and the .NET context is not available. Thus, object references cannot be passed to native code; instead, they have to be marshaled into a form that is suitable for native code. Collectively this process is named interop, and it allows you to call code outside of the embracing arms of .NET.

You might have your own libraries, and these could be written in a variety of languages and provided as COM, DLL-exported functions, static-link libraries, or even C++ template libraries. If this code is provided by a third party, you'll often have little choice other than to access that code through interop. If these libraries are written by your company, an argument is needed to port such code over to .NET. However, porting is not always a viable solution because you'll multiply the amount of effort that you'll put into testing and debugging the code—not only do you have to test your new code, but you also have to test your ported code. Furthermore, the .NET Framework is based on different paradigms than most Win32 code, and there is rarely a one-to-one equivalence. It is almost always better to use this code in the environment where it was originally designed and access it through interop.

When you execute code through interop, the native code has direct access to memory. This access is not tracked by the garbage collector, and code access security is not applied; code access security gives code permissions based on evidence provided by the code, which includes the code's source location. (See Chapter 5 for more details about code access security.) You get the advantage of increased performance because the .NET Framework does not make checks on native code (run-time type checks, code access checks, bounds checks on array indices, and so on), but you risk the associated danger that because these run-time checks are not performed, the code can modify memory that it does not own.

You can use interop in several ways, as described in the following list. I'll cover each approach in detail in the rest of this chapter.

• It Just Works! (IJW) This technology is available only through the Managed Extensions for C++. With IJW, you use native code directly. You do not need to add any other code; the compiler generates all the code to call to make the transition to native code.
• Platform invoke This technology is accessed through custom attributes, and it allows you to access code exported as C functions from a DLL.
• COM interop This technology allows you to access COM objects as if they were .NET objects and .NET objects as if they were COM objects.

COM interop allows you to use .NET types from unmanaged code as if they were COM objects. The .NET code will run in an apartment in the native process— the client code does not have to be compiled with a .NET-specific library. Of course, if the .NET code runs on the same machine as the client, you have to make sure that the code and the .NET Framework are deployed on the client machine. If the code is accessed remotely¹ or if it is installed as part of a COM+ application on a remote machine, the client machine need know nothing at all about .NET.

If you want to have more control in your native client, you can decide to create your own application domain and call .NET code from there. This strategy really makes sense only if you want to have more control over how application domains are created and over their run-time properties. I will cover the details of creating application domains and calling .NET components in those domains in Chapter 5.

¹  Through sockets, SOAP, or ASP.NET, but not through .NET remoting, which requires the runtime on the client.