Visual Studio 2005 Team Edition for (unmanaged) C++ Developers

If you're a C++ developer who writes mostly unmanaged C++ code, you may wonder what parts of Visual Studio 2005 Team Edition for Developers apply to you. It's a reasonable concern.

I did a little research and found an excellent post from Rob Caron that links out to dozens of C++ related Team System articles. But it's a little scattershot. A lot of the functionality is inherent to Visual Studio 2005-- not necessarily Team System.

Chris Idzerda (our CTO and a star C++ developer) and I sat down and worked through all the Developer functionality in C++ to figure out what parts of the Developer Edition are helpful for C++ developers. We quickly found that there's a huge divide between native C++ code and managed C++. You can still get many of the benefits of Team System in native C++, but you'll get the most benefit if you're using managed C++.

Here's what we found when we tried using the Team Edition for Developers functionality as an unmanaged code C++ developer:

  • Unit tests

    Unit testing works best for Managed C++ code. In fact, it works identically to unit testing for C# and VB.NET. However, if you're testing unmanaged C++ code, you can still benefit from VSTS unit testing. You have three options:

    1. Create a new managed C++ test project. After creating the project, in the project options, set the General, CLR from /clr:safe to /clr. You will not get auto-generated unit tests, but this will work.
    2. Write a managed C++ wrapper for your code. Then auto-generate the unit tests.
    3. Create a new test project in any language, then call your existing code using [DllImport] or COM interop.

    We think the best options are #1 and #2. We have a sample C++ project in Visual Studio 2005 that demonstrates option #1. Note that this is not the only way to integrate managed C++ test code with unmanaged C++, but it worked OK for us. Check it out and see what you think.

  • Code Coverage

    The code coverage story is a bit strange for unmanaged C++ code. But it does work! We got it to work by following John Cunningham's series of posts (one, two) that explain exactly how to do it. We manually instrumented our executable, manually ran the tests, the results were automatically gathered, and we were able to manually double-click on the resulting *.coverage file and show source code highlighting. Very cool! Although a bit, er, manual..

  • Code Analysis

    Under the project properties, you'll notice both Static (General, Code Analysis) and Dynamic (General, Application Verifier) analysis options.

    It looks like the dynamic half of the analysis, Application Verifier, is enabled by default.

    However, you'll need to flip the switches in the Code Analysis sections to enable static analysis warnings. As usual there's a big divide between managed and unmanaged C++ code here; the managed code gets the same comprehensive FxCop-style code analysis you've seen in VB.NET and C#. Unmanaged code can only use the "Enable Code Analysis for Managed Binaries" option. Here's a screenshot from MSDN of the warnings the unmanaged C++ code analysis.

  • Code Profiler

    The good news is that code profiling works nearly identically for unmanaged C++ as it does for C# and VB.NET. However, there is one limitation: only memory allocations for .NET objects can be tracked. If you're writing unmanaged C++ code, you probably aren't allocating any .NET objects. And even if you're writing managed C++ code, you may not be allocating many .NET objects. So keep that caveat in mind.

In general, most areas of Team Edition for Software Developers do work for C++ developers. They even get a few goodies that the rest of us don't, such as the Application Verifier. That said, there's a lot of subtle encouragement to switch to managed C++ development, too.

posted on Friday, September 29, 2006 5:16 PM by jatwood

Comments

# re: Visual Studio 2005 Team Edition for (unmanaged) C++ Developers

VSTS has a great static code analysis tool strictly for unmanaged C++ code. You need to set the /prefast switch on the compiler to enable it. It's based on the technology we use internally in Microsoft to statically analyze all our C++ sources before a product is shipped. Together, static analysis and the profiler, are in my opinion the best tools for C++ developers that make VSTS compelling.

Also, worth mentioning of course is the bug tracking tool (which we internally use as well).
Tuesday, October 03, 2006 11:31 AM by Tarek Madkour [Microsoft]

# re: Visual Studio 2005 Team Edition for (unmanaged) C++ Developers

In the first option, under unit tests you mention creating a new test project with /clr or /clr:safe. We have attempted write tests using this method against native non-clr projects (dlls) and found the generated output unreliable. In several cases we have found that the v-tables used to make calls from the test code to the dlls to be invalid and result in access violations and the like. Tests can also result in inconsistent results when run on different machines. Can this method be implemented reliably? Does anyone else actually use this method or do you always compile all code as '/clr' (managed) first?
Sunday, May 27, 2007 7:47 PM by skennedy