ASP.NET Is Multilanguage

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.


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.