tl;dr

Is it just me or is this still rather half-baked, even now in 2008? Everywhere I turn I run across tiny little rough edges. Like this one: I am using Team Suite 2008 to generate code coverage data during a unit test run. I hit Run Tests and get 48 test run warnings, one per test/per referenced DLL, that say

“Code coverage instrumentation warning while processing file FooBar.dll: Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process.  The CLR header flags have been updated to reflect this.”

So, yes. It simply cannot do code coverage on a 64-bit process. I’m running Vista x64, so naturally Visual Studio is starting up a 64 bit process, which the code coverage tool immediately fiddles with the CLR to drop it back to x86. This generates tons of sprurious warnings which (to top it all off) can be disabled on the comman line but not apparantly in the GUI. God knows what would happen if I were unit testing some subtle bug that only happened on the x64 platform.

On top of this, you still can’t Edit And Continue a running piece of code in the debugger properly if you are running x64. On my old Windows XP x64 workstation, it flat out didn’t work; now on Vista x64, it requires some messing around to breakpoint all running threads before it lets you get into the code.

I guess there must be some deep seated bits of the Windows API with some strongly held assumptions of 32 bittiness behind the scenes, and that what I am seeing are the rough edges of that hackery.

Personal