For the past few months, I've been running up and down the halls, hollering "C-Sharp rules!" I'll stick my head into an editor's office, pumping my fist in the air, and yell, "Web services rock!"

Judging from the way people now close their doors when they see me approach, I'm guilty of being a .NET spaz. Fine. I can live with that. What I can't live with, though, is that—like just about everybody who's talking about .NET—;I've fallen into a trap. By focusing on the fancy, flashy features of VS.NET, we've perhaps given the impression that's all there is to it.

Shame on me.

To correct that situation, I recently interviewed Tony Goodhew, Microsoft's Visual C++ product manager, asking him what features in VS.NET aren't getting the press they deserve. Here are a few things we talked about.

Managed Extensions: When VS.NET was first announced, Managed C++ got no respect, mostly because it was treated as nothing but a bridge—a way to transition your existing code over to the .NET Framework.

While that's an acceptable use of this technology, it's certainly not the only one. Instead, think of Managed C++ as your portal to the .NET Framework, both for old and new apps. Thanks to Managed C++, you'll be able to call native C++ classes from .NET apps, or call .NET components from C++. You can even mix native C++ code and Managed Extensions in the same app, giving you the best of both worlds—power, flexibility, access to legacy code, and integration with other .NET components, whatever language they were written in.

Can VB.NET do all this? No. Can C# do this? Sorry. Can any other language claim these benefits?

Nope. The fact is, Managed C++ is what sets VC++.NET apart from all the other languages; it's what gives VC++ developers the edge over absolutely everybody else. Expect to hear much, much more about Managed Extensions in upcoming issues of VCDJ.

Simpler COM Deployment: Right now, deploying a COM component is pretty aggravating. You've got to copy it to the server, then run regsvr32 against it to create an entry in the Registry database. Then, when you want to update it (as you'll almost certainly need to), you're in big trouble. You've got to stop the server, change the component, and restart. Grrrr. With .NET, you create the COM component by copying it to the server; as long as it's in the path, it'll be installed for you. Further, you can have multiple versions of the component, letting apps decide which version to instantiate. Nice.

.NET Compact Framework: This small-footprint version of .NET should reduce the development chasm between desktops and small devices. It's a pared-down version of the framework, including a core set of base classes, with special sets of classes for handwriting recognition, speech recognition (for mobile phones), and so forth, as well as device profiles for things like set-top boxes and PDAs. You'll use the full-blown VS.NET to develop your app, then just copy it over to the Compact Framework. No cross-compiler necessary.

Attributes: When VS.NET was first announced (way back when we used to call it VS7), Attributes—built-in declarative keywords for common tasks—were the first big thing. Now you never hear about them at all. That's too bad, too, because this feature really has the potential to make your life easier. First of all, Attributes are pervasive. You'll have access to them whether you're coding with native C++, Managed C++, or C#. Second, Attributes let you avoid having to scroll through big chunks of generated code, while still providing access to that code if you need it, courtesy of the /fx compile switch. Learn what Attributes are available and you'll save a heap of coding time.

Is that all the forgotten VS.NET features? Not even close. But it's a good start. And while you can count on VCDJ to continue covering stuff like C#, Web services, and XML, you can bet that we won't be ignoring these "forgotten" features, either. Which means, of course, that I have a whole new batch of reasons to be excited about .NET.