The Visual Studio Tech Roadmap — Starring Visual Studio 2010

[I’m moving some my more interesting old blogs from web archive to someplace they can actually be found. Keep in mind these were written a lot time ago.]

[Note there are lots of embedded links here, I have no idea if they still work in 2022]

• 11/18/2008

Dear Readers:I wrote a followup posting Visual Studio Dialogue with WPF Performance Emphasis based on the comments below and there was a related interview on Channel 9: Visual Studio Futures — Extensibility Video, I include those links here for easy reference.

Well the time has finally come for me to start writing about my new job in earnest. My long time readers know that I became Chief Architect of Visual Studio in the summer of 2007 and I’ve been working on Visual Studio 2010 issues since then. Well actually, believe it or not, I’m already working on whatever comes after that too but let’s not get ahead of ourselves.

So what’s the plan for 2010?

Well before I get into that you should know that lots of the things I will be writing about are still under development and while I talk about things I want to see, or wanted to see when these plans were created, that’s not the same as them being in the product. 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. So, while it’s true that I have a significant effect on what we do, it is inadvisable to take any of what I write as some kind of commitment to deliver particular features; rather I talk about examples of things that we might do that are in line with the roadmap. That’s an important distinction and one that is frequently lost by commentators.

Still with me? I hope so. OK, the plan.

When we first started looking at our issues for this wave, and even going forward, we established a few major themes that we wanted to work on over the course of the next several releases. We wanted to make large scale improvements on a long time scale and we didn’t want to “go dark” for several years and then release some new development environment that magically solved all our problems — we opted for a long term plan to “remodel the product.” So, how do we think about that? Here are the major themes, keeping in mind that I don’t want to write a novel :)

Visual Studio Should be Extensible

How can I stand here and tell you that it needs to be more extensible when nearly the whole thing is already an extension? I mean if you launched Visual Studio with no extensions at all you’d get basically an empty frame with a File Exit menu or something like that. How can it be not extensible, it’s ALL extensions, right?

Well, yes, but… not so fast. The core of Visual Studio is very extensible but many of our customers do not want to extend the core, they want to extend the extensions. Now the story gets a lot more complicated. How do you extend those? Sometimes you can, sometimes you can’t, and there isn’t consistency about the mechanism either. Compounding this difficulty, we universally get requests for a managed extensibility solution — less COM, more simple managed components.

This calls for a change of strategy.

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.

If you’ve seen demonstration of the new editor then I hope you’ve been blown away by what you can do with a real fine-grained extensibility model in this space. Fairly simple components can make pervasive and highly valuable extensions. This is not your grand-daddies editor.

Our long term plan calls for more MEF extensibility in each release, not a massive rewrite but again, a gradual remodel.

Visual Studio Should be Modern

If you put VS2008 side by side with say VC98 they would certainly look different. But, even though they are different, could your mom tell you which one was made in 1998? I’m not 100% sure my mom could tell. Sorry mom. OK suppose you put the 1988 IDE side by side with the 1998 IDE. Could your mom tell? I’m pretty darn sure she could.

Being modern isn’t about just having the latest trendy look and feel. Though I’d like to have that too. It’s about being able to take advantage of the latest hardware and experience advances. Can we make use of today’s GPUs? Are we going to be ready for many-core CPUs? Pervasive high-speed networks?

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?”

I certainly don’t think so, and, so far, nobody I’ve asked has been able to answer in the affirmative either. So we could stick our head in the sand and pretend WPF doesn’t exist or we could start investing in the future.

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.

There’s more we will do. Some of our code is has deep OLE entanglements because of its STA nature and this prevents us from taking advantage of multiple cores in the way we would like to. We’ll have to start addressing those as well… again, it will come in steps but there is much to do now, some of it invisible, so that we have the technology we need when we need it.

Visual Studio Should be Scalable and Frugal [1]

It’s easy to assume that since we’re taking a dependency on WPF, that we’re planning to do work, for instance, in the editor (a core asset), and in the start page, that VS will necessarily get bigger. That the new editor, being WPF, must necessarily be slower.

That’s defeatist tripe.

The fact of the matter is that the existing VS codebase is far from ideal, and while we will certainly be loading more code at startup that doesn’t mean that we can find other wins elsewhere so that on middle to large sized solutions we can pay for the cost WPF. I know there are areas that can use improvement, we did a lot of work of this ilk in VS2008 and there is still more we can do. Larger solutions can use upwards of 1G of memory, even a 10% savings there would pay for the cost of loading WPF many times over.

And there’s more.

Our existing editor is definitely showing its age. Many of the key supporting algorithms for tracking regions have very poor (quadratic) performance characteristics and so they slow down massively as file size increases. These algorithms were fine in the past but as region tracking supports more and more features the size of the files and the number of regions has continued to increase. In some cases these significantly affect even basic scrolling speed in the old editor. This doesn’t need to be the case, there are other choices for region management with much better scalability.

Additionally, any extender of the old editor can tell you that it did not offer a consistent buffer snapshot model so in cases (like say VB) where we want to do a background compilation, we are forced to copy the entire buffer on every keystroke so that the compiler gets a consistent image. I think we can do a lot better than that.

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 :)

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.

Visual Studio Should be Connected

I’ll deal with this one briefly because this posting is already far too long for my taste.

We didn’t just invent Windows Azure for the rest of the world, there are many excellent services that a development solution can/should provide/consume. It doesn’t all have to be cloud-based either: Basic peer-to-peer collaboration scenarios are increasingly important, buddy programming, local services, lab scenarios, and so forth. VS2008 has a fairly limited set of connected offerings, that’s something that has to improve as part of our roadmap. Our Team <*> offerings are already heading down this path and I think there is room in the Pro version for some of this as well… especially in the 10 year time-frame.

Conclusion

Well, this is just a taste of what I’ve been thinking about. It’s the direction I’ve been driving for the last year and a half. Later I’ll do a posting on specific initiatives that came out of this, things you are likely to see, some of which I’ve mentioned above and some which I haven’t. I want to reinforce again that this is not a laundry list of features, this is about describing the kinds of things we wanted to consider and the way we will approach our technology roadmap for many releases. I hope you’ll find it helpful even though, like everything else I write, it’s offered “as is, with no warrantee.”