Try this. Open up Visual Studio and make yourself an MFC app. It doesn't really matter what kind of application it is - a dialog app is probably the quickest to create but you could use some more complex MFC app that you happened to have lying around if you preferred. Build the app and run it to prove to yourself that it's fine.

Now bring up the project properties, and under Configuration Properties, General set Common Language Runtime Support to Pure MSIL Common Language Runtime Support.

Click OK and build the application. Blam! Errors everywhere. My little nothing dialog application got 18 and they all look like this:

What does this mean? Well, every function has a calling convention. These include __stdcall, __clrcall, __cdecl, and so on. Many of the functions in the MFC libraries (look at the include files for which these errors occur) are declared to be __stdcall, meaning that they are common-or-garden native C++ functions. But when you compile your application /clr:pure, you are saying "I don't have any common-or-garden native C++ functions in here. Everything is managed."

Since you can't change MFC, you have to change your compiler options. Change the CLR support to just "Common Language Runtime Support (/clr)" and build again. All the errors go away.

Kate

Thottam R. Sriram has an article in the January MSDN Magazine called CLR Inside Out: Introduction to COM Interop. As the introduction says:

COM is a wonderful technology. One aspect of the common language runtime (CLR) that makes it an extremely powerful platform is that it allows seamless interactions between Microsoft® .NET applications and unmanaged COM components. However, when I searched the Web, I found few working samples demonstrating the very basic concepts of COM interop. The purpose of this column is to illustrate those basic concepts in order to provide solid working examples that can jump-start users in this technology.

I'll start off with a simple Active Template Library (ATL) COM server and try accessing methods in this server using an unmanaged COM client, then do the same thing with a managed client. I'll walk through the various DLLs to illustrate the translation from unmanaged to managed, and I'll show how to access an exported method in an unmanaged DLL using P/Invoke. The toughest part of this is to figure out marshaling of complex structures, which I don't cover exhaustively in this column-it would be a complete column (or book) on its own. I'll show you how unmanaged code can call back into managed code using interfaces. (You could do this with delegates as well, but I won't cover that in this column.)

Finally, I'll discuss debugging your COM interop project using public symbols. This will give you very basic introduction to WinDbg.exe, unmanaged debugging, and managed debugging using SOS. I'll demonstrate the stack from managed to unmanaged as calls are made in either direction.

The managed client is in C# -- when you write your clients in C++/CLI you don't have to figure out how to declare and marshal complex structures, after all. And seeing how to call back from native code to managed code is helpful indeed. I'm not sure if Reverse P/Invoke is the official name for this, but it works for me. You set up an interface in your C# code and decorate it with attributes for COM. Then you implement that interface in your code and use tlbexp to make a COM Callable Wrapper around your .NET object. Then you hand-define the same interface as a COM interface in your native code and you're all set. The .NET code can P/Invoke some native function and pass in a reference to the .NET interface. By the time it's unmarshaled over in the native world, it's become a smart pointer to that COM interface and you can invoke the method from the native code. It's a little tricky, but it's not hard - once you've seen it done.

Since the article wraps up by touching on Windbg, there's something for everyone. Check it out!

Kate

I read an interesting blog entry at Dumb Little Man. Essentially, the story goes like this. A guy is fed up with his job, doesn't like it, is ready to quit. Instead he throws himself whole-heartedly into it and gives it his all. He does the tasks he dislikes, he does tasks he isn't asked to do, he speaks up and speaks out, and he becomes so much happier in the job. And if that wasn't enough, he gets a two-layer promotion and a $15,000 a year raise.

His list may not precisely work for you. You may not be asked to do TPS reports, whatever they are. You may live a life like mine where no one can give you a promotion. You may not think that working long hours is important to success at your company, or worth what you have to give up in your private life. But look past the details of his particular list. What would happen if you totally threw yourself into what you are doing now and really really did it?

Kate

Here's another reason to install Visual Studio SP1 - it fixes one class of "intellisense stops working" problems. Intellisense stops working a lot for C++ developers. It doesn't happen very often for me, but people mention it quite often when I speak and some of my coworkers are less lucky than I am because it happens in their day to day work.

If Intellisense stops working for you and you're working on a C++ project, the workaround is to close Visual Studio, find and delete the .ncb file, and re-open Visual Studio. As you can imagine, that cuts into flow quite a bit. Now a KB article mentions that SP 1 fixes "In a Microsoft Visual C++ 2005-based solution that includes multiple projects, the IntelliSense of a project does not work correctly if the project references types from another Visual C++ or Visual C# project." Cool!

Kate

Jeff Atwood has a fun post explaining how much more quickly he finds things now that he can once again just type the names of programs. It's so true. Instead of clicking Start, All Programs, Microsoft Office, Microsoft Word Whatever, with the attendant pauses while the menus come up and the pauses while I desparately scan the huge list looking for the thing I know has to be there somewhere, it's just press the Windows key and type word, then press enter. Or perhaps type w if I'm lucky enough. The search is blazing fast and there's the application I want, or the file I want, or the control panel sub-thingy that has a new name now so I can't see it. Ah, typing. I never really gave up on typing. And now it's once again one of the main ways we'll interact with the operating system.

And not just because of the way cool search thing. There's the UAC aspect to this too. Open yourself an elevated command prompt, and everything you launch from that command prompt will be elevated -- no manifest, no right-click Run As Administrator, just run your utility so you can do whatever administrative tasks you need to do in relative peace. Small price to pay: you have to type the names of those apps (possibly with their full paths) into the command prompt.

And that's not the only deja vu I get as a Vista user and developer. Does anyone remember making Windows applications before, say WinForms? OK, before VB or before MFC? Before there was a framework that gave you an object called Button that had a property called Text or Caption or the like, how did you set the text on a button? You sent it a Windows message (WM_SETTEXT) with a parameter of "Save" or whatever you wanted.  Well you don't have to do that any longer, but how do you arrange for the shield icon to appear on a button? (It's a convention that if clicking a button is going to pop up an elevation consent dialog, you put the shield on the button.) By sending it a BCM_SETSHIELD message, of course!

The longer you've been programming, the less jarring these things are. Soon enough the tools will catch up and it will be all drag-drop, set properties etc. If that's all you've ever known, you might feel like Vista has dropped you through the looking glass. But if you have some memories of the old days, you're going to be on more solid ground. And you probably still type really fast.

Kate

Eric Appel recommends installing SP1 for Visual Studio 2005 and the Visual Studio 2005 SP1 Update for Windows Vista Beta. Let's drill into that name a little bit more. Starting at the end, it's a Beta of Visual Studio 2005 SP1 Update for Windows Vista. That is in turn an "Update for Windows Vista" of "Visual Studio 2005 SP1". You have to start with SP1 first. But SP1 has nothing to do with Vista. 

SP1 is a common-or-garden service pack for Visual Studio. It fixes a pile of little things that were found in Visual Studio. Some are just syntax colouring, some are real issues. And it can be argued that you should only install it if you need it. There are some issues with the service pack itself: Heath Stewart has a summary with workarounds where they are known. It can take a long time to install, and you should make sure you have enough disk space, because if the install fails the rollback is a little overenthusiastic ... you might have to reinstall Visual Studio 2005 to make sure certain libraries are in place. That said, lots of people are glad they installed it.

If you want to install the update for Vista, then you need to install SP1. And once you've done that, you'll find many things both simpler and faster. Happy me.

Kate

Poor Visual Studio 2005, aka Whidbey. Developed and released before Vista, it's Vista-blind. Say you're building a COM component and one of your build steps registers it, writing to something under HKLM. Unless that instance of Visual Studio is running elevated (perhaps because you right-clicked and chose Run As Administrator) the registration will fail. The fix: close Visual Studio, run it again elevated, repeat your build. It's a little frustrating.

Every month that goes by is going to make this better. Eric Appel has a nice summary of what you can do now: install a pair of updates (one released, one in beta) and set Visual Studio to always run elevated. You'll need to consent every time you run it, so I actually skip this, run non-elevated most of the time, and when something fails I close and re-open Visual Studio.  If you would find that super frustrating, go ahead and mark it to require Administrator. It's also a good habit to test by double-clicking your EXE in Windows Explorer rather than hitting F5, so that your app is elevated or not elevated according to its own manifest and not according to the way you started Visual Studio.

It's a transition time. It won't last forever.

Kate

Eric Lee has spotted the Vista-programming-is-easier-with-C++/CLI phenomenon for himself.

... I have really come to enjoy the second incarnation of managed C++, now called C++/CLI. Unless you are really good at .NET marshalling, a lot of great Windows Vista features just aren't that accessible from .NET.  This is where C++/CLI really comes into its own.

He gives a nice example featuring a preview handler. Preview and thumbnail handlers are really cool in Vista, but you have to implement some COM interfaces to do it. His final conclusion:

I'm pretty pleased with how C++/CLI gave me a way to mix what C++ and ATL do pretty well (COM, Shell Extensions, etc) with what .NET does pretty well (user interfaces, dnd design, etc).

Best of both worlds! I have a slide or two that say that

Kate

The January Orcas CTP is ready. The new C++ features include .NET Framework Multitargeting (allows the user to target different versions of the .Net framework from a single instance of Visual studio) and Library Versioning (renaming assorted libraries with 9 in their names because they differ from the current versions.) There's a handy list of Orcas features and which CTP they first appear in on MSDN. To view the documents, you'll need an XPS viewer unless you're already using Vista day to day.

Community Technology Previews are not as fully tested as betas, but they're here now, and you can provide feedback after working with them, so why not take a look?

Kate