Back to Extending VS.NET Home

What's In It For You?

Q: 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 bulletproof 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 of 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. 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." 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.

Q: 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 does 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 and 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.

Bill Taylor: The Intermediate Language was a great way for us to simplify how we do integrate our runtime analysis tools with VS.NET because we do our instrumentation at the IL level.

Peter Varhol: Whether it be the IL or the metadata, I think it's correct to say there is a common ground already in Visual Studio. It might be a least common denominator, and we might work up from there to find a more seamless way of exchanging data going on into the future, but right now there are adequate tools, whether it be the IL or the metadata of the Framework itself, for exchanging the information we need for tools that work with multiple languages, and for multiple languages to work more seamlessly with one another and to componentize more easily.

Dean Guida: One of the things we're excited about is that—now that you can truly reuse components in the .NET platform and inherit and extend them—that's really going to give developers a level of productivity they haven't had in COM. Yes, we had COM integration, but now have true extensibility. You can now buy prepackaged components and then customize them for your own specific applications.

What Is VSIP?

Know the Issues