The Visual Studio Tech Roadmap — Starring Visual Studio 2010

[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.


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."

Comments (27)
  1. Steven Raybell says:

    The thing that miffs me with WPF is cleartype.  There’s not facility whatsoever to turn it off, from what I can tell and have researched, for WPF based applications.  This alone makes me worried to all heck about the future of my favorite IDE (and being a C# developer, this is even more important to me).

    Please, please, please let me disable that mess that is cleartype.  For me, it isn’t clear, and gives me nearly instant eyestrain and headaches.

    I’d hate to be forced to use fonts that don’t fit my needs as well just so that I can have some supposed "new and exciting" interface in an arena where I just don’t need it.  I’d wager that other developers don’t need to be graphically wowed by their IDE either.

    I’m more than willing to even talk more in a one-on-one scenario as I, too, work here in Redmond.  Heck, I’d even appreciate it to give my feedback further.  🙂

    I know of others that care about this as well, on my team no less.  I’m sure they’d be interested as well.

  2. Sam says:


    Great article and great direction to take this excellent product. I love the idea of integrating azure like features. Buddy coding would be great. An integrated iphone like app store for VS extensions would be great for the various extension developers.  

    I guess a few questions that tie in:

    1. Will the new design of VS allow me, the end-user, to disable a bunch of features (because of the clean extensibility model) to such an extent that VS launches as fast as notepad and acts as fast as it? I know its not such a realistic example but I think it a really admirable goal.

    2. Will the new design of VS allow me to better diagnose issues with visual studio. For example if my cpu suddenly jumps to 100% will I be able to find out that component XYZ is responsible, and disable it? I’m thinking something like Google chromes task manager ..

    3. You did allude to API simplification on the extensibility side, I think this is fantastic, are you going to have the freedom to break backwards compatibility?      

    4. In a tie in question, what improvements are you looking at around profiling and diagnostics, a tool like ants profiler baked in perhaps?

    Again, great article and I think you are on the right track.

    On a side, fairly insignificant note compared to all the rest. Will you be looking at providing proper support for developing MCML apps in VS.Net? (I’m tired of pushing xml around) I’ve advocated for quite a while that they should get rid of that technology and replace it with WPF but it seems not to be happening …



  3. I am very excited about the changes.  I look forward to seeing tools like Resharper take full advantage of the new extensibility model and WPF-based editor.

    Take it with a grain of salt, though, I’m a cheap sell for shiny objects.

  4. JudahGabriel says:

    Wow. Rico, I think you’re the first person I’ve talked to in a long time that "gets it".

    So many people are on either side of the camp: either the

    "go back to VC6 luddites/we don’t need no stinkin’ gradients" camp

    or the

    "don’t worry about how much resources we consume" camp.

    Additionally, you’re not saying, "Hey, I’ve got a brilliant idea. Let’s rewrite the damn thing." Instead, you’re taking the high road and doing a remodel.

    I’m encouraged by what you’ve written in this post! And I’m really looking forward to Rico’s VS2010!

  5. Daniel Smith says:

    Moving over to WPF is fine if, and only if, it’s not at the expense of *any* end user experience/functionality.

    Microsoft is famous for not getting 100% there and then saying "that’s as much as we could fit into a v1 release".  Leaving any features that are replaced with WPF with reduced functionality is simply not an option.

    If you can’t at the very least keep the feature set on par, then it’s absolutely not ready to be replaced with WPF.

    Remember – developers are a picky and unforgiving lot!

  6. Pop Catalin says:

    VS10 and WPF is the most exciting thing about VS, ever :), I’m sure WPF will be used for much more than a pretty UI, it will be used for a more functional and dynamic UI. Finally something that gets me over excited about VS10.

  7. WPF Controls Jaime Rodriguez – Jaime did a quick port of the Chart controls from the Silverlight Toolkit

  8. Anders Borum says:

    Hi Rico,

    It’s great to see the emphasis on a more reponsible use of memory. Unfortunately, a lot of developers don’t care about memory usage and subsequently end up with applications don’t scale.

    I agree with the WPF part. Using WPF as the graphics foundation for VS should definetely warrant a lot of focus for getting the best performance, features and scalability out of that graphics framework.

    One thing that VS currently don’t do very well is managing really large files (e.g. XML files of 64 or 128 MB). It’s just not ideal to check these files for data using the IDE (other editors have better formance I’m sure, but I’d like to stick with VS).

    Don’t forget to keep us posted 🙂

  9. pingpong says:

    I don’t care about looks, but I can imagine lots of MS fanboys really need that.

    Make VStudio responsive (like VC98 IDE) and scalable and I’ll be happy. I don’t really think you can achieve that with WPF in the product core. Good luck anyway.

  10. R.J says:

    IMO UI look is in a lot lower priority.

    1. Performance

    2. Extensibility

    3. Low memory usage

    4. Developer productivity

    These are important to me.

    I believe currently WPF is against #1 and #3.


  11. Tanveer Badar says:

    You hit it on the right spot. IDE literally dies when working on files with > 5K lines.

    Please do something to improve that horrible experience, generations will worship you.

  12. zdeslav says:

    It’s great to hear the next release will focus on extensibility and more efficient memory usage.

    However, i don’t see that much benefit in moving to WPF: "Do you really think GDI is the last word in computer graphics for the next 10 years?"

    In all truth, VS2008 isn’t really that much ahead of my old Turbo C 2.0 as you would expect from 20 years of constant improvement, but I guess that there will be people who will drool on eye candy.

    The bigger issue for me is optimization of common tasks. You say: "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…"

    The startup is not the only pain point, please also consider shutdown. I typically run 2 or 3 instances of VS, and when I try to close one or more, I have to wait for a long time, until finally I get tired and kill it in ProcessExplorer. This is a common scenario for me and most of my colleagues, and there are many other places when users have to wait because of some seemingly innocuous operation.

    And as someone already noted: allow me to turn off everything I don’t need, and tweak the environment to the way I prefer to work. That single improvement would make it worthwhile to move to VS2010.

  13. JM says:

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

    My response? "For IDEs? I sure hope so."

    Make it fast, make it scale, make it extensible. There’s still too much to gain in these areas to be bold about eye candy.

    And I know I’m being unfair when I’m dismissing a potential move to WPF as "eye candy", but the bar is very high if you want to create an interface that’s radically more usable than what we’ve already got. Which I hope would be the point of moving to WPF.

    IDEs aren’t supposed to be wow material in the UI department, so what’s with wanting it to be "modern" in the first place? It should mesh well with the OS, but beyond that, anything that doesn’t translate to developer productivity gains is, IMO, a waste of human and technical resources.

    I do see the benefit to MS for dogfooding their own UI technology in their flagship product, but that’s more a service to WPF than it is to VS, and as a backend developer I’m more than slightly biased against it.

  14. Yesterday I read this great article about VS.NET&#39;s technical roadmap , posted by Rico Mariani . Rico

  15. Weekly digest of interesting stuff

  16. willdean says:

    Great post Rico, and great video with Paramesh on C9.

    If it wasn’t for you being on the VS team, the news about WPF in VS10 would have made me weep.

    I was *so* glad to see that Anders managed to get a dig in about VS perf not once but *twice* in his PDC talk.  

    The current VS is shockingly bad for perf and I reckon 100M developers’ hopes are pinned on *you* Rico to get it fixed.   Don’t fail us, please!

  17. Wayne says:

    Speed.  100% this is my biggest gripe. solutions that take FOREVER to build and deploy and load, etc.

    Do this for me, start filewatcher and then open a VS ASP.NET project.  When you see 1000’s of file open requests (duplicates in many cases) you will see the issue.  What about build – dont get me started – there are 10s of 1000s of file open requests, checking and most are duplicates.   The Hard drive is the slowest thing on a computer – so could you guys not figure out to use it as little as possible?

  18. Fabrice says:

    I strongly agree with Wayne. The best optimization that can be done is on speed, and most likely through better and fewer file accesses.

  19. Peter says:

    Great post and great suggestions in comments. Here’s my list (in order of importance)

    1) Ability to disable clear-type! I can’t stress enough! I can’t handle clear-type for more than a few minutes. Not sure about you guys, but I can see the pixel on my monitor, and that anti-aliasing makes things blurry, not clear.

    2) Performance, performance, performance!

    I can live with slow start-up, shut-down, or large memory usage. I really don’t need animations or much glitz; I’ll take it if it helps though. My #1 complaint with the current version is the ASPX editing (not the designer, I’ve given up on that a long time ago). It interrupts my flow all the time by giving me the hour glass — may as well give me the finger. My understanding is that this is because of the background stuff that it needs to do and can’t dump into a separate thread. If WPF can help here, then it can’t come soon enough.

    However, it needs to be so good that I won’t even be able to know that it’s WPF based. If you can’t get the performance at least to the level of the current editor then please don’t even try. Thanks.

    P.S. Have I mentioned performance?!

  20. Peter says:

    Look at Paint.NET and look at SQL Server Management Studio. Both written in .NET, one feels like a WinForms application, the other doesn’t. To be clear Paint.NET kicks SSMS’s butt, so it can be done. I haven’t played with Blend and other WPF applications yet.

  21. Rico, your WPF reasoning sounds concise and may be even convincing, but you restrict yourselves down the same old path of "dogfooding new and cool windows technologies".

    Why don’t you take a shot at a paradigm shift for a change? Why don’t you hire 3-4 game developers in your team, experts in 3D, custom UIs and *performance*, and then build a whole new IDE that is NOT a windows application at its core but a DirectX "game"? I have seen mind-blasting UIs from game devs (not in the games themselves but in the dev tools for the games). I am sure you can find a couple of super-highly-talented game devs to add to the picture.

    Warm Regards

  22. Wyatt says:

    All I want out of VS2010 is for the RAM usage not to double.  I run a lot of IDE instances (I have 5 copies of VS2008 running now), and everytime I’ve upgraded to a new version of Visual Studio, I have to double the RAM in my machine.

    VS2003 – 1GB

    VS2005 – 2GB

    VS2008 – 4GB

    At the rate this is going, VS2010 is going to require a 64-bit OS.

  23. 墙头草 says:



  24. [記事リンク]Visual Studio 2010のロードマップ

  25. CurlyFro says:

    how about stepping up the client side IDE for better intellisense and debugging?

  26. TraumaPony says:

    As a game developer, I’m worried about WPF hogging the GPU during testing.

    Also, you repeatedly make the point "could your mother tell the difference between VC6 and VS08?" My response to that is, "does it matter?" I couldn’t care less that my IDE looks like something straight from 1998. Why does it have to -look- new, if it already has so many new features?

    On the other hand, I’m definitely looking forward to it. Just as long as I don’t have to relearn the GUI, and it doesn’t use too many resources.

Comments are closed.

Skip to main content