Extending Visual Studio .NET
FTP convened a roundtable of industry experts to discuss VS.NET's extensibility and integration options.

VSLive! SF, Day 3, February 14, 2002 — Patrick Meader, Editor in Chief of Visual Studio Magazine, moderated a panel of industry experts convened by Fawcette Technical Publications to discuss Microsoft's extensibility and integration programs for Visual Studio .NET. Panelists included: Dr. Basim Khadim, Chief Software Architect of Languages for Fujitsu Software Corporation; Bill Fisher, CEO at Summit Software; Bill Taylor, Director of Developer Marketing, Rational Software; Dean Guida, CEO, Infragistics; Mani Gill, Senior Program Manager on VS.NET Integration, Crystal Decisions; Peter Varhol, Product Manager of the DevPartner product line at Compuware; Rich Little, President of Lead Technologies and President, Component Vendors Consortium; Robert Green, Visual Studio Lead Product Manager, Microsoft; and Steven Roth, CTO, Wise Solutions. .NET Insight will point to the roundtable discussion in an upcoming issue. Here's a short excerpt of the conversation, to whet your appetite:

Patrick Meader: How will the multilanguage capabilities and third-party developer tools extending the .NET platform affect developers?

Peter Varhol: In the past, developers have traditionally chosen a language based on the strengths and limitations of that language. So you had C++ developers who did so because of the bullet-proof nature of the language, recognizing that the development cycle was a little bit longer. You had VB developers who chose that particular language for its RAD capabilities, recognizing it might not be as scalable as a C++ application, and so on. You chose your tool based on the characteristics of the tool. I think a lot of that will be going away under VS.NET. As all the languages become available under VS.NET and generate IL—where the IL is in fact what's executed—it will matter significantly less whether you're a C++ developer, a COBOL developer, or a VB developer. They'll be more VS.NET developers than specific-language developers.

Basim Kadhim: There's often a real divide in organizations that have COBOL legacy code. The COBOL programmers are on one side of the house, the VB programmers are on the other side of the house, and some of that is because of the lack of commonality in tools and infrastructure. A lot of organizations have struggled with that, and I think that's why there's been a lot of pressure to move away from COBOL because a lot of organizations didn't feel there was a future for either their COBOL code or their programmers. But with VS.NET bringing those things together, providing a common infrastructure, you now have the opportunity to bridge the divide and make it easier for developers to work together.

Mani Gill: When you've got the third-party vendors building some stuff, and then you've got language vendors building some stuff, there is always the possibility for a lot more scenarios than, "Well, my tool works only with Visual Basic." The one thing that I've seen—and after thinking about this topic a little bit more—there will need to be some standards set amongst these different tools. For example, if COBOL.NET wants to take advantage of Crystal Reports, out of the box it just wouldn't work because there are certain additional types of features that aren't accounted for. For example, with VB, we test for code generation. To get code generation to work for COBOL, either COBOL would need to do something or Crystal would need to do something.

Patrick Meader: That leads me to my next question: Are there any special issues you need to be aware of when extending or integrating into VS.NET to account for all the differences between the languages that VS.NET will support?

Basim Kadhim: It's true there has to be some agreement between tools, but some of that already exists in Visual Studio. There's certainly a tension when you provide a framework like Visual Studio in terms of providing enough extensibility and flexibility, and then constraining certain parts of the design space. There are parts, like the code model, for example, that uniformly specify how to do code generation, which a number of languages can leverage from. It's true for designers, as well. There are various pieces that language vendors can integrate to more easily play with a lot of the third-party utilities. This is not to say that in a lot of cases these things work out of the box—there does tend to be some level of handshaking because these designs by necessity have to be somewhat flexible—more loosely coupled in the way they integrate. But it is true that there is some level of coordination at the level of the APIs provided.