Presenting the VS 2010 Roadmap

Posted by Jonathan Allen on Nov 20, 2008 06:27 AM

Community

.NET

Topics

IDE

Tags

Visual Studio

Rico Mariani, Chief Architect of Visual Studio, talks about the long term plans for Visual Studio 2010. Before we get into it, Rico does have a warning,

I am the Chief Architect but I'm also *only* the Chief Architect, I don't make the final decisions about what goes in the product, not even combined with the other architects. Jointly we come up with the long term technology roadmap, it indicates key problems that need to be solved for the long-term health of the product among other things, but these things cannot usually be mapped directly in to features in a particular release.

First up is extensibility. While the core of Visual Studio is extensible, many of the higher-level components that people actually want to extend are mostly off limits. In addition, the extensibility points are largely based on COM.

So to meet these needs we embraced what became known as the Managed Extensibility Framework (MEF) and two major extensibility areas in Visual Studio 2010 import and export according to that standard. Now of course MEF was just a gleam in our eyes when we started but as you can see from what we're able to show in the PDC bits we've come a long way there. We've taken major MEF dependencies in both our new Text Editor (more on that below) and in the new C++ project system.

In the future Visual Studio will rely heavily on Windows Presentation Foundation. This has gotten mixed responses from the public.

This may sound like a no-brainer but there is often resistance. Let me pick my favorite issue for VS2010 -- using WPF pervasively. Many people, at least initially think I'm nuts to advocate taking that dependency. "Can you afford it? What about scenario <X> I heard WPF isn't so good at <X>." I've been pretty much silencing dissent with the following observation:

"Do you really think GDI is the last word in computer graphics for the next 10 years?"

He continues,

I know we are bound have some problems with WPF. We have to fix them, and who better than us? We've done medium sized WPF applications (e.g. Blend), and now we're going to drive a Flagship Application, maybe the 3rd largest suite in the world (I dunno exactly but it's up there), right down WPF Boulevard and we're going to Make It Work. It will be great for us, and for WPF itself, and then others can follow with confidence. There is no real alternative because we can't just sit here on our old UI and then expect to magically have a modern look in 10 years. And our friends in WPF-land are just as excited about this as I am... maybe more so if that's possible.

Throughout the article, a common theme is comparing VS 2008 with VS 98.

I did a quick demonstration for my VP last year where I showed a simple MFC application build and debug scenario in VC98 vs. VS2008 -- and don't get me wrong, I think VS2008 made great progress on this front and I think it's a great product, but --- suffice to say that VS2008 used quite a lot more memory to do the same job as VC98.

Yes of course VS2008 can do more than VC98, but seriously, I think there is room to improve here. Remember I was around for C6.0, I have a long memory :)

When asked about making Visual Studio 64-bit, Rico scoffs at the idea.

Sometimes people tell me we should go to a 64 bit solution to get the scale we need. I think that's wrong, I think what we need is to use less memory not more memory, I think we have non-lazy algorithms in some key places and we need to address those. That's what I'm pushing for. I don't want us take act like we have even more memory -- we might move in the wrong direction if we do that. But we do need a 64 bit plan and that's something for another posting.

• Older >