File size

File size

File size

22.2 MB

The new Historical Debugger coming in Visual Studio Team System 2010 promises to revolutionize the way you debug managed applications. You can think of it as something of a VCR for your debugger; "rewind" the debugging trace to examine the state of your
application at various points in time so you can all-but-eliminate the guesswork about where to place your breakpoints prior to pressing F5.

The SKU plans haven't been locked yet (or if they have, marketing hasn't told me ) but unless something changes this feature will be limited to people using the Development or Suite editions of Team System.

I know this will cause some angst since it's such a cool feature, but that's the business of building and selling developer tools... gotta pay the bills.

There's one workaround that I just found out from the product team, and that is that you can set your build configuration to x86 and the F5 scenario will work. F5 doesn't work when your app is targeting x64.

The other scenarios outlined on Habib's blog (such as being able to collect historical debugger trace data while your automated or manual tests are running) will work with x86 or x64.

To add to Brian's point about 64-bit support, in the F5 scenario, our collection mechanism (i.e. how we collect information about a process) is specific to 32-bit processes. Unfortunately, we didn't have enough time to implement 64-bit support and had to
make a hard cut. You can bet that 64-bit support is one of our top priorities after the VS2010 release.

The 64 bit explanation was bit confusing in the video. What I got from it was that you need 32 bit cpu and OS for the f5 scenario. Or does the f5 scenario work with 64 bit cpu and OS when debugging 32 bit (non- any cpu) managed app?

I am not aware of any other features which are limited to 32-bit only but if I find any I will post them back here. Rest assured that supporting 64-bit is a very high priority for us, and as Habib points out there's a workaround to allow you to use the Historical
Debugger by setting your target CPU to 32-bit in VSTS2010. Not ideal... but switching from a 32-bit to 64-bit world is a journey.

My apologies, that was my fault for making the video confusing since I had a different understanding when I originally learned about this limitation. The 64-bit limitation during the F5 scenario is only about the target application being 64-bit; you can
still be developing on a 64-bit machine as long as you set the target CPU to be 32-bit. Other scenarios such as collecting the debugging trace files (which can be consumed by the historical debugger) while running your tests are supported on both 32-bit and
64-bit hardware, regardless of your application's target CPU.

Right... but I often find that customers perception of your (any) platform is that if an application crashes it's interpreted as "Windows crashes". In other words the stability of ISV applications gets confused in customers mind with the perception of your
platform as a whole. I understand the point that the devdiv team needs to report to the bean counters, it's just a shame to see a debugging tool become exclusive. Please, please don't limit the availability of concurrency developer supports - helping the
wider software industry transition to a many core world is something Microsoft is in a almost unique position to deliver on. Visual Studio and Blend *are* my desktop, I love these tools, it's just sad to see passionate younger engineers out there in the community
get behind a new feature only to have to it denied them.

Hi Dot_Tom - I totally understand what you're saying. We're investing in a lot of capabilities around application quality which will not be limited to the Team Edition developer.

In terms of concurrent development I believe that all of those features will be available in VS Pro. Nothing is baked until the marketing team announced it as such, but I don't believe based on what I know today that you'll be missing anything here.

Brian

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.