Introduction to .NET Languages
In other sections previous to this, we have examined the runtime and the Common Type System. Essentially then, a .NET application can be thought of some code to manipulate these types and call methods in the Base Class Library, along with the application's logic. .NET compilers are of different types. .NET Consumers include compilers that let you do simple compilation of script code. On the other hand, .NET Extenders, let you take and extend existing Common Type System types. .NET language compilers do not compile your code directly to X86 (with the exception of one mode of the Visual C++.NET compiler). Instead they emit metadata and MSIL opcodes to an Assembly. The MSIL in the Assembly may be just-in-time (JIT) compiled at runtime and executed by the runtime.
What is the heart of all this? As we explored already, the heart is the Common Type System. As we saw on that page, the Common Type System defines a comprehensive type system that all languages that play in the .NET runtime must follow. It is important to note that it does not require all .NET languages to map every type to a language feature nor specify how. The base set of features that a .NET language compiler must support to allow cross-language interoperation in the .NET Runtime is defined by the Common Language Specification. To obey these rules, is to generate types that can be used by code generated by other CLS-compliant .NET complilers.
Obviously, this is what Microsoft call the .NET Runtime, the Common Language Runtime. But what does the runtime execute? It does not execute C# or VB.NET. It always executes MSIL opcodes. The IL generated by all the .NET Language Compilers is more or less exactly the same (there are some exceptions in the code generated by Visual C++.NET). This leads to the argument that the language that ones uses in .NET is completly irrelevant as they all generate the same IL and therefore some even claim that you can develop parts of your application in different languages and put them together.
Is this valid? In theory yes. In pratice, no. In pratice, just about every software company has a lot of time and money invested in a certain langauge that they will continue to use, Unlike Win32 development and especially n-tier development with WinDNA which required a whole slew of languages and technologies, .NET is more likely to accelerate developers using one language of choice and making use of the BCL from that language. They key thing for development shops however, is that all languages, have virtually equal access to the BCL. There are some differences between C# and VB.NET, however, these tend to be small.
The first thing to say is that you do need VS.NET to do .NET development. You can use the link above and using notepad and the compilers, certainly do lots of .NET development. What does VS.NET bring to the table? Well, language-sensitive editors with IntelliSense, management of compiler options and assembly references, hosts the VS.NET debuggers, and an extensible environment for doing all of your application development. The great win for developers is that we finally have one environment for all the main Micrososft languages!
One of the interesting things to me is that most of VS.NET is a managed application. However, it is clear that the extensibility and add-on model are still COM based unmanaged code.
VS.NET is even more extensible than previous versions of Visual Studio. Previous versions had what was known as an "extensibility model." VS.NET offers a much enhanced full, rich "automation model" allowing you the capability of customizing any aspect of the IDE and adding the capability of macros. This "Common Environment Object Model" is available to all .NET languages. There are basically four ways to extend the VS.NET IDE:
1. VSMacros - Macros allow you to record actions but there is also a fill-blown Macro IDE where you may use the Visual Studio for Applications language (which is essentially VB.NET)
2. Add-ins and Wizards
3. The VSIP program
My experience has proven that the new automation model is extremely powerful and the mechanism of compiled addins and wizards can accomplish many industrial-strength tasks without the need to go to VSIP. Of course, to fully become a part of the IDE, VSIP is needed.
Working with the Automation Model
The most important object in the model is the topmost one, the DTE object, which is the design-time envionment, or the IDE itself. DTE stands for "Development Tools Extensibility." Most of the actions in the IDE are actions performed on the automation model. To prove this, select "Tools - Macros - Record Temporary Macro" in VS.NET and then select "File - New - Project" and then "Visual C# Projects - Windows Application." Now stop recording and right-click on the Macro name and walla - up pops the brand new Macro IDE. Your code will look something like this:
Option Explicit Off
Public Module RecordingModule
You can see that many of the commands in the IDE are available through the DTE object.