Comments on: COM Nature of Visual Studio - Good or Bad? http://www.professionalvisualstudio.com/blog/2008/04/11/com-nature-of-visual-studio-good-or-bad/ Tips, Tricks, and Best Practices for professional .NET developers Wed, 19 Nov 2008 22:50:11 +0000 http://wordpress.org/?v=2.6.1 By: Darren Stokes http://www.professionalvisualstudio.com/blog/2008/04/11/com-nature-of-visual-studio-good-or-bad/#comment-110 Darren Stokes Fri, 11 Apr 2008 23:58:03 +0000 http://www.professionalvisualstudio.com/blog/2008/04/11/com-nature-of-visual-studio-good-or-bad/#comment-110 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. 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.

]]> By: Anna-Jayne Metcalfe http://www.professionalvisualstudio.com/blog/2008/04/11/com-nature-of-visual-studio-good-or-bad/#comment-108 Anna-Jayne Metcalfe Fri, 11 Apr 2008 07:18:33 +0000 http://www.professionalvisualstudio.com/blog/2008/04/11/com-nature-of-visual-studio-good-or-bad/#comment-108 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. :) 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. :)

]]>