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.

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

Comments

• Anonymous
  November 18, 2008
  PingBack from http://mstechnews.info/2008/11/the-visual-studio-tech-roadmap-starring-visual-studio-2010/

• Anonymous
  November 18, 2008
  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.

• Anonymous
  November 18, 2008
  The comment has been removed

• Anonymous
  November 18, 2008
  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.

• Anonymous
  November 18, 2008
  The comment has been removed

• Anonymous
  November 18, 2008
  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!

• Anonymous
  November 18, 2008
  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.

• Anonymous
  November 18, 2008
  WPF Controls Jaime Rodriguez – Jaime did a quick port of the Chart controls from the Silverlight Toolkit

• Anonymous
  November 19, 2008
  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 :-)

• Anonymous
  November 19, 2008
  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.

• Anonymous
  November 19, 2008
  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. Thanks,

• Anonymous
  November 20, 2008
  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.

• Anonymous
  November 20, 2008
  The comment has been removed

• Anonymous
  November 20, 2008
  The comment has been removed

• Anonymous
  November 20, 2008
  Yesterday I read this great article about VS.NET&#39;s technical roadmap , posted by Rico Mariani . Rico

• Anonymous
  November 21, 2008
  Weekly digest of interesting stuff

• Anonymous
  November 21, 2008
  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!

• Anonymous
  November 21, 2008
  Speed.  100% this is my biggest gripe.  Asp.net 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?

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

• Anonymous
  November 21, 2008
  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?!

• Anonymous
  November 21, 2008
  The comment has been removed

• Anonymous
  November 24, 2008
  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

• Anonymous
  November 25, 2008
  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.

• Anonymous
  November 25, 2008
  RicoMariani，VisualStudio的首席架构师，近期谈到了有关VisualStudio2010长期计划的情况。在我们跟进此事之前，Rico先来了个预防针： 我是首席架构师，但是...

• Anonymous
  November 27, 2008
  [記事リンク]Visual Studio 2010のロードマップ

• Anonymous
  December 02, 2008
  how about stepping up the client side IDE for better intellisense and debugging?

• Anonymous
  December 12, 2008
  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.