Probably you know that Visual Studio, this popular and common development IDE for .NET developers, is over 11 years old and has been an IDE for development from the early days.
When Visual Studio was created originally, the common development technologies were all based on COM programming so Visual Studio was created based on a COM infrastructure.
Those days this wasn’t anything uncommon or special and all developer around the globe were using it. After the birth of .NET technology and its new infrastructure that is completely different from COM, Microsoft didn’t rewrite its IDE to be compatible with new stuff and just applied and updated the existing IDE for .NET development.
Here (the birth of .NET) was a point that changed many things around this IDE. Regular development scenarios and many developers don’t notice the side-effect of keeping the COM nature of Visual Studio but the fact is that this COM nature is now showing its bad effect on this IDE from the extensibility point of view.
Visual Studio is strongly correlated with its COM infrastructure and almost everything is an implementation of an interface. Microsoft has tried to adapt the existing IDE for newer technologies and hide the core API to some extent.
On the other hand, Visual Studio IDE for .NET development (versions 2002, 2003, 2005 and 2008) are great examples of interoperability between .NET and COM in its highest level.
By the way, this wouldn’t be important for anyone but two groups of developers. First groups are those who work at Microsoft to add new features for development to it and the second group are VSX developers. Both groups of developers should deal with extensibility features of VS and lower levels of its API.
If you begin working with Visual Studio Extensibility then you will notice the side-effect of this COM nature after a short while. Here those who don’t have a good background in COM programming, have some difficulties to learn VSX and this is a negative point for VS because new age of developers wouldn’t know much about COM.
One of the good strategies that Microsoft is considering for VS is hiding the lower level APIs from developers who want to extend Visual Studio just by building a .NET infrastructure on top of these APIs. For instance, when you work with code snippets or Visual Studio templates, you don’t deal with anything related to these low level APIs at all.
But unfortunately this is just for some stuff that aren’t strongly correlated with low level API. So all professional VSX developers have to work with COM-related stuff and this is one of the main negative points that a newbie faces with!
Actually, for us this is a good thing - we develop our VSX products using native code, which allows us to target all Visual Studio IDEs from 2002 onwards (as well as the legacy VC6 and eVC4 environments) with a single binary built using Visual Studio 2008.
We simply couldn’t do that with a .NET implementation due to the in-process versioning requirements of the framework (believe me, I looked into it at the outset).
This sort of implementation isn’t as tricky as you’d expect, actually. With COM smart pointers most of the grot is well and truly hidden (who uses raw interfaces these days anyway?), and we’ve got good support libraries to back up our development.
There is still quite a bit of native windows development going on, especially for commercial software. I know that many products for Visual Studio still use the COM api’s from native code even though the .net alternative exists. This is mostly due to intellectual property and code protection issues (.net being far easier to decompile than native code) but also due to performance.
I think it would be difficult to get a .Net implemented Visual Studio to be fast enough for the native windows development community.
One large inconvenience that you didn’t mention was windows forms control development. Since the winforms designer in Visual Studio is implemented in COM, there is some cross app domain marshalling that goes on and causes problems during development. Developers must be extra careful to clean things up during the debug/test/dev cycle or weird problems will occur.
All this said, I believe the real answer comes down to money and quality. It would be a very expensive undertaking for MS to rewrite Visual Studio and would take a long time to get that rewritten application to the quality level that the dev community expects. In the end, this large expense would only benefit those extending Visual Studio using the .Net api’s which is probably less than .01% of the overall .net dev community.