6 Comments

  • I don't know this for a fact, but I believe I've heard/read/made up in my own mind/etc that the fact that Office is still COM is why VS.NET is as well, because all the menuing and all that I believe is directly taken from Office. I could be wrong, but that's my guess and I'm sticking to it!



    My next thought was, hhhmmm...maybe performance? But then that gets you thinking...what does that say about managed code? :P



    Where's Josh on this one? :P

  • For quite some time I have thought that it has to do with reuse, that a lot of VS.Net is not written in .Net or managed code.



    I think DTE is an example...



  • My guess (which isn't any more authorative than anyone else's) is that the VS.NET is built heavily on the previous VS 6 codebase, which was built on the one before it, etc. When most of your code base is 3-4 years old (and probably has certain artifacts dating back even more) you don't have lots of architectural fliexibility.

  • hey Roy - i've got some addin suggestions on my blog, specifically for your competition. No time to code any myself.



    DTE, by the way, is all legacy code, wrapped up for use in VS.net. The design decision behind this, I think, is that until VS.net was a more stable product (ie after two or three versions) it wasn't worth rewriting the extensibility components. Craig Skibo talks about it in that book, "Inside Visual Studio .Net" -- but I don't have it on me at the mo'.



    Best of luck with the competition.

    Leon Bambrick

  • Certain core parts of the basic plug-in architecture of the VS extensibility model will be changing in the Whidbey. Most of the conjectures here are, for the most part, accurate in one way or another. Heavy VS6 foundation. Same interfaces in EnvDTE as you may recognize when previously building COM add-ins. The menus (context menus, commandbars, etc) are all from Microsoft.Core.Office interop namespace. I concur that it is overly complicated, but when it does work well, just very annoying at times.



    Notice that VSIP Extras came much later than VSIP, so even the uber-integration APIS provided by VSIP followed the same legacy/unmanaged code route first, then VSIP extras brought in managed goodies (extras by name).



  • Why doesn't VB.NET have Edit & Continue?

    Why doesn't C# have generics?

    Why do winforms still wrap the old Win32 APIs?



    I think it's just a time issue. Sure, they could have made a totally managed VS.NET add-in architecture, but that might have delayed the release of .NET for 6 or 9 months (or more?).



    You can't get everything in the first go-around. :)

Comments have been disabled for this content.