DevPartner Studio 10 - unmanaged disappointments

The story so far, I’ve owned DevPartner Studio for several years and been on a support contract the whole time. The support situation went a bit flaky when Compuware sold the product to Micro Focus, I expect that either I’m simply not a big enough client for them to care or their post sales and support is just no where near as good as the Compuware offering. With Compuware I’d be contacted when new versions came out and I had a named sales contact that I could also use for questions, etc. What’s more the sales guy was good, he knew I wouldn’t be buying more licenses, he remembered the issues I’d raised and he helped chase up responses etc.

Anyway, I whinged about how DevPartner lagged behind Visual Studio releases and was told, via a comment from someone at Micro Focus, that DevPartner 10 shipped at the same time as Visual Studio 2010; it would have been nice if my support contract meant that they’d bother to tell me about this since I was entitled to the latest version; heh, here’s an idea, the software itself could work it out for me somehow (nah, nobody would do that)… Anyway, it seems that the way I’m supposed to work out that a new version that I’m entitled to under my support contract is available is to log on to the Micro Focus support site and ‘request a new version’. Presumably I either poll this site every couple of months and request current version + 1 or I’m supposed to track when they release new versions… Interestingly I get a list of patches for 9.1 displayed but no indication that a 10 is available…

So, I fill in the form and wait a few days, no response, I chase them and eventually get an email with some download links. I download and install DevPartner 10 and run it up in “Error detection” mode on an unmanaged VS2010 solution which contains a relatively simple multi-threaded project…

During the build I get several compiler crashes and whilst it IS the Microsoft C++ compiler that is crashing here it has never crashed with this code if DevPartner instrumentation is NOT enabled… The errors are all similar:

1>e:\source\practicaltesting\jetbytetools\testtools\testmonitor.cpp(748): fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x524EDFBA:0x00000004]', line 183)
1>   To work around this problem, try simplifying or changing the program near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information

And they all occur in these kinds of situations…

   }
   catch(const CSEHException &e)
   {
      cout << "Exception during test timeout processing: " << CStringConverter::TtoA(e.GetWhere() + _T(" - ") + e.GetMessage()) << endl;
   }
   JETBYTE_TESTS_CATCH_ALL_AT_THREAD_BOUNDARY_IF_ENABLED
   {
      cout << "Unecpedted exception during test timeout processing" << endl;
   }

Where the macro evaluates to catch(...) in this particular build.

So, my first impression of the new version is that it’s just about as good as the first impression I had of 9.0, i.e. it simply doesn’t work on the latest compiler with simple code. I don’t know if I’m alone in thinking that when software that you’re supposed to rely on for software quality assurance work gives this kind of first impression you tend to worry if it actually does what it needs to at all, rather than simply being a rushed to market mess which underwent too little testing before release so that it could be shipped at the same time as the new compiler without actually supporting it…

Anyway, I thought, perhaps, that by default there were too many error detection options turned on (I tend to use a small subset of the functionality as I’ve found that the more interesting stuff is prone to not work (API parameter checking is great until you realise that some of the (admittedly many) APIs that it covers are configured incorrectly and report problems that don’t exist and you can’t change them and have to wait for a service release…). Anyway, off I go to the options screen and find that I can’t change the error detection options as “Error Detection settings are unavailable until you select a valid start up project”…

At this point I switched to VS2008 to see how things were back in the legacy compiler environment. This time everything builds OK but when I go to run the program under BoundsChecker I get a message telling me that DevPartner is unable to test 64bit projects. Fair enough; we’re still in ’tool lag’ country, DevPartner 9.1 could also only ‘run on’ x64 and not instrument x64 code; then the tool would also try and instrument the x64 builds but the link failure messages were fairly clear in what was wrong. It’s a pity that the DevPartner 10 user interface isn’t consistent on this, the VS2010 options screen obviously knows it’s not supposed to let you work with x64 projects (though could be more helpful) yet the tool bars and build process let you try to build x64 projects rather than, more helpfully, preventing you…

Rebuilding the 32bit version of the code in VS2010 worked OK, but what a wonderful first impression…

Now there seem to be some new weird problem reports inside of the VS2010 STL code which I need to dig my way through to determine why they’re OK to ignore…

And then I suppose I need to go and dig up all of the same information that they already have about my development machine so that I can ask them to send me a new license file…