Not only does this architecture support Microsoft's languages, the modular plug-in nature allows for language modules from other vendors to be dropped in as well. This means that the .Net classes are available to other languages that you or your programmers might be more experienced with, that are better suited to the task, or that a lot legacy code that you're trying to bring up to speed has been already been written in. For example, for tasks that involve a lot of text parsing, perhaps you're preference is to use Perl. ActiveState has you covered with a Visual Perl module for VS.Net that turns your Perl code into MSIL. Or perhaps you have a lot of legacy code written in Cobol. Both MicroFocus and Fujitsu make Cobol modules that drop into VS.Net.
OK. So Microsoft did a good thing in building multi-language support into the Visual Studio IDE thus allowing programmers their choice of language for developing applications to run on its runtime enviroment (RTE) . But what if your preference is to use one of the Java Runtime Environments (JREs) such as J2ME, J2SE, or J2EE as your RTE. While it's doable, Sun hasn't exactly endorsed or promoted the idea of scripting JREs with languages other than Java. As Sun's Tim Bray puts it in a recent blog entry,
"Java has a PR problem; while Microsoft marketed the .NET stuff as multi-language from day one, the fact that Java is a three-legged stool (language, JVM, libraries) kind of gets lost under the enveloping carpet of the one-word name