Scott Guthrie: Visual Studio 2010 and .NET Framework 4.0 | Matthijs Hoekstra

40th Floor

re: Around the 30 minute mark, about the debugger "going back" and no other debugger doing that. Watcom's debugger did that way back in 1995. For OS/2 anyway. At the time, it didn't seem all that WOW. 15 years of doing without... WOW!

ahillyer

The camera person stinks....why do they have to keep zooming out so you can't read the screen or zoom in on Scott? You rule Scott but I want to see what you're demoing, not you or the entire room!

matthargett

In reply to malovicn

#Sep 28th @ 4:25 PM

I agree -- ReSharper implements most of these features better, especially the TDD workflow.

Scott's demo of the TDD workflow pretty much misses the point of TDD and required so much extra typing to allow the IDE to correctly infer things. It should have been able to read like this:

var controller = new HiScottController();

var result = controller.SayHello();

Assert.AreEqual(result.ViewName, "HiScottController");

The IDE should be able to infer the class name, method name, and supply a very narrow list of potential types for the SayHello() method (based upon the symbols used on the 'result' variable) that the user can choose between.

Showing people that Assert.IsNotNull() passes on a result from the 'new' operator (which will always be true, and the IDE should have inspected and warned you as such like IntelliJ/ReSharper does) not only shows people the wrong way to think about TDD, but is a poor way to sell these new feature sets.

It's disappointing to see Microsoft going through the motions of attempting to emulate ReSharper's feature set as a checklist, rather than understanding the intention and innovating a solution based upon the root problem. As least the extensibility improvements should help the next version of ReSharper integrate more deeply without disruption from VS service packs.