ASP.NET Fundamentals: ASP.NET is Multi-language
ASP.NET is Multi-language. Though you’ll probably opt to use one language over another when you develop an application, that choice won’t determine what you can accomplish with your web applications. That’s because no matter what language you use, the code is compiled into IL.
IL is a stepping stone for every managed application. (A managed application is any application that’s written for .NET and executes inside the managed environment of the CLR.) In a sense, IL is the language of .NET, and it’s the only language that the CLR recognizes.
To understand IL, it helps to consider a simple example. Take a look at this code written in C#:
using System;
namespace HelloWorld
{
public class TestClass
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
}
}
}
This code shows the most basic application that’s possible in .NET—a simple command-line utility that displays a single, predictable message on the console window. Now look at it from a different perspective. Here’s the IL code for the Main() method:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 13 (0xd)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Hello World"
IL_0006: call void [mscorlib]System.Console::WriteLine(string)
IL_000b: nop
IL_000c: ret
} // end of method TestClass::Main
It’s easy enough to look at the IL for any compiled .NET application. You simply need to run the IL Disassembler, which is installed with Visual Studio and the .NET SDK (software development kit). Look for the file ildasm.exe in a directory like c:\Program Files\Microsoft SDKs\Windows\v7.0A\bin. Run ildasm.exe, and then use the File ➤ Open command, and select any DLL or EXE that was created with .NET.
Tip: For even more disassembling power, check out the remarkable (and free) Reflector tool at http://www.red-gate.com/products/reflector. With the help of community-created add-ins, you can use Reflector to diagram, analyze, and decompile the IL code in any assembly.
If you’re patient and a little logical, you can deconstruct the IL code fairly easily and figure out what’s happening. The fact that IL is so easy to disassemble can raise privacy and code control issues, but these issues usually aren’t of any concern to ASP.NET developers. That’s because all ASP.NET code is stored and executed on the server. Because the client never receives the compiled code file, the client has no opportunity to decompile it. If it is a concern, consider using an obfuscator that scrambles code to try to make it more difficult to understand. (For example, an obfuscator might rename all variables to have generic, meaningless names such as f__a__234.) Visual Studio includes a scaled-down version of one popular obfuscator, called Dotfuscator.
The following code shows the same console application in Visual Basic code:
Imports System
Namespace HelloWorld
Public Class TestClass
Shared Sub Main(args() As String)
Console.WriteLine("Hello World")
End Sub
End Class
End Namespace
If you compile this application and look at the IL code, you’ll find that it’s nearly identical to the IL code generated from the C# version. Although different compilers can sometimes introduce their own optimizations, as a general rule of thumb no .NET language outperforms any other .NET language, because they all share the same common infrastructure. This infrastructure is formalized in the CLS (Common Language Specification), which is described in the following sidebar, entitled “The Common Language Specification."
It’s worth noting that IL has been adopted as an ECMA and ISO standard. This adoption allows the adoption of other common language frameworks on other platforms. The Mono project at http://www.mono-project.com is the best example of such a project.
The Common Language Specification
The CLR expects all objects to adhere to a specific set of rules so that they can interact. The CLS is this set of rules.
The CLS defines many laws that all languages must follow, such as primitive types, method overloading, and so on. Any compiler that generates IL code to be executed in the CLR must adhere to all rules governed within the CLS. The CLS gives developers, vendors, and software manufacturers the opportunity to work within a common set of specifications for languages, compilers, and data types. You can find a list of a large number of CLS-compliant languages at http://dotnetpowered.com/languages.aspx.
Given these criteria, the creation of a language compiler that generates true CLR-compliant code can be complex. Nevertheless, compilers can exist for virtually any language, and chances are that there may eventually be one for just about every language you’d ever want to use. Imagine—mainframe programmers who loved COBOL in its heyday can now use their knowledge base to create web applications!
