Extending MFC Applications with the .Net Framework

Book's Assumptions and Goals

This book assumes that you are an experienced MFC developer who, while not ready to completely migrate your code to .NET, is interested in seeing how .NET can make you more productive. As an MFC developer, you're infinitely more comfortable with the document/view and dialog model of creating user interfaces and are simply much more productive with this development environment. In addition, you might have a large amount of source code that you're not willing or able to migrate to .NET right now—if ever. However, you're still intrigued by some of the .NET classes and how they might compliment or even replace various MFC counterpart classes. That is specifically who this book targets. As opposed to the many .NET books that seem to take the attitude that it will be all or nothing for developers, this book is more realistic in realizing that many developers (especially those using C++ and MFC) will want to use .NET only where there is a clear and obvious advantage.

One important point to make here is that this book is not a "Managed Extensions" book in the truest sense. In addition, while I do go into some detail on the various .NET classes that I illustrate throughout this book, this book is not a ".NET class library book." There are hundreds of .NET types and classes and that simply isn't the focus here. My objective is to show you a select few classes that I feel would benefit most MFC developers. An example of that would be the XML chapter.

XML has become the standard for exchanging data in many organizations. However, in order to use XML from MFC, you're probably going to be using the Microsoft IE (Internet Explorer) XMLDOM via COM.While this is workable solution—I've written several articles and book chapters on how this is done—using the XMLDOM just doesn't compare to the very elegant and powerful set of .NET XML classes. Therefore, a complete chapter is devoted to the .NET XML namespace—covering everything from reading/writing XML files and traversing XML documents to querying XML data using XPath and making XSL transformations—all from an MFC application!

As a result of this approach, when finished with this book, you will know how to use IJW in order to enhance your existing—and future—MFC applications with the .NET classes that interest you most; thereby making you a more productive—and marketable—programmer.

Technical Preface

Before getting started, let's clear up some definitions as that will dovetail nicely into the goals and organization of this book. While it's sometimes helpful to think of Visual C++.NET as containing two separate C++ compilers—one for managed (.NET) code and one for unmanaged code—technically, the Visual C++.NET product contains only one compiler that has two distinct parts:

• Sum ISO Standard C++: This ISO-compliant C++ compiler can be used (with the inclusion of the appropriate libraries) to generate native (x86) executables and libraries for projects such as console applications, Windows applications, Windows services and so on. When combined with the MFC class library, this is what pays the bills for most of the intended readers of this book (and its authors).
• Sum Managed Extensions: These refer to the language constructs available for mixing managed C++ syntax with your standard C++ code. The managed extensions allow you to define and use managed types (garbage collected reference type, value types, scoped enums, delegates, etc.), and use managed runtime facilities such as reflection and security.

There are actually two types of COM Interop. There is the COM Callable Wrapper (CCW) that allows you to create a "pure" native application (with no .NET build-time dependencies) that accesses .NET code via COM and the Runtime Callable Wrapper (RCW) that allows you to access native code from managed applications. Therefore, one direction I could have taken in this book would have been to write MFC applications and then access the various selected .NET classes via CCW. However, CCW has many drawbacks that inevitably make it unappealing. First, CCW is not very efficient in terms of execution speed. Second, CCW cannot use the entire CLR type system—method parameters and properties are restricted to automation types. Finally, many .NET types are not exposed to COM so accessing them would be very difficult to impossible.

So what about IJW? IJW—which stands for It Just Works—refers to the collection of mechanisms that allow managed code to call native functions, compile unmanaged types in MSIL, use unmanaged types in managed type method signatures, provide native entry points to MSIL methods, etc. However, IJW is not only about managed code calling native functions. It's also about exposing native entry points to managed functions and basically doing all the plumbing necessary to get C++ code to work under .NET.

If you're a bit confused by the last paragraph, that's perfectly understandable. After all, it now sounds like I'm talking about writing .NET applications that use native code when the book's topic promises to be about the opposite—using .NET to augment MFC applications! As it turns out, while at first blush, this does seem to be backwards and the designers of IJW probably intended it for .NET applications that need to occasionally call a native function, it turns out that it works just fine for a .NET application that is 90 percent native. As a result, since IJW has full access to the .NET class hierarchy and type system and is much more efficient than CCW, this is the technique used throughout the book.