Benefits of a Common Language Runtime

• Language functionality :The choice of language is now a lifestyle choice, rather than a functionality choice, as they are all equivalent. Use whatever language you are happiest with.

• Performance :The .NET languages were designed to provide high performance. The only difference between the languages is at the compilation stage, where compilers may produce slightly different MSIL.

• Platform support :The languages sit on top of the CLR, so if the CLR is available on a platform, then so are the .NET languages. For small device support and 64-bit platforms, this makes portability far easier than with previous Windows languages.

Common API

In the previous version of Visual Studio, common functionality was always harder to implement than it should have been. For C++ programmers, the Windows API is a natural home, but Visual Basic programmers had to use custom controls and libraries, or delve into the API itself. This isn't complex, and can yield great benefits, but there is no consistency.

With .NET, you now have a common API and a great set of class libraries. For example, consider the case of TCP/IP network applications. C++ programmers generally write directly to Winsock, whereas Visual Basic programmers prefer to use custom controls on their forms. The .NET Framework provides a System.Net.Sockets namespace encompassing all of the networking functionality, and its usage is the same for each language.

For example, consider the case of writing to a UDP port “ notice that the only differences in the code are the syntax of the language.

The code in Visual Basic .NET:

  Dim Client       As UdpClient   Dim HostName     As String   Dim HostIP       As IPHostEntry   Dim GroupAddress As IPAddress   Dim Remote       As IPEndPoint     HostName = DNS.GetHostName()   HostIP = DNS.GetHostByName(HostName)     Client = New UdpClient(8080)   GroupAddress = IpAddress.Parse("224.0.0.1")   Client.JoinMultiCastGroup(GroupAddress, 500)   Remote = New IPEndPoint(GroupAddress, 8080)   Client.Send(".NET is great", 13, Remote)  

The code in C#:

  UdpClient   Client;   String      HostName;   IPHostEntry HostIP;   IPAddress   GroupAddress;   IPEndPoint  Remote;     HostName = DNS.GetHostName();   HostIP = DNS.GetHostByName(HostName);     Client = new UdpClient(8080);   GroupAddress = IpAddress.Parse("224.0.0.1");   Client.JoinMultiCastGroup(GroupAddress, 500);   Remote = new IPEndPoint(GroupAddress, 8080);   Client.Send(".NET is great", 13, Remote);  

Common Types

Cross-language functionality is made available by use of common types. Those Visual Basic programmers (and I was one) who delved into the Windows API always had the problem about converting types. Strings were the worst, because the API is C/C++ based, which uses Null- terminated strings, so we always had to do conversion and fixed string handling stuff. It was ugly. With the CLS, there is a common set of types, so no conversion is required. The conversion of native types into CLS types is shown in the following table:

Type	Visual Basic .NET	C#
System.Boolean	Boolean	Bool
System.Byte	Byte	Byte
System.Char	Char	Char
System.DateTime	Date	No direct equivalent. Use the CLS type.
System.Decimal	Decimal	Decimal
System.Double	Double	Double
System.Int16	Short	Short
System.Int32	Integer	Int
System.Int64	Long	Long
System.UInt16	No direct equivalent	Ushort
System.UInt32	No direct equivalent	Uint
System.UInt64	No direct equivalent.	Ulong
System.SByte	No direct equivalent	Sbyte
System.Single	Single	Float
System.String	String	String

Note

Not all languages have equivalents of the CLS types. For example, JScript.NET implements dates using the standard JScript Date object. However, you can convert between various type formats, as well as declaring the CLS types directly.

Cross-Language Inheritance

Another area where the CLS has helped is inheritance. If you use the common types in your class interfaces, inheriting classes written in other languages is no different to that of inheriting from the same language. There was a brief example in the previous chapter, when discussing the CLR and common functionality, but a fuller example makes this clear. For example, consider the following Visual Basic class:

  Public Class Person     Private _firstName As String   Private _lastName As String     Sub New()   End Sub     Sub New(firstName As String, lastName As String)   _firstName = firstName   _lastName = lastName   End Sub     Public Property FirstName() As String   ' property code here   End Property     Public Property LastName() As String   ' property code here   End Property     End Class  

You could write another program, perhaps in C#, that inherits from it:

  public class programmer : Person   {   private int _avgHoursSleepPerNight;     public programmer(): base()   {   }     public programmer(string firstName, string lastName)   : base(firstName, lastName)   {   }     public programmer(string firstName, string lastName, int hoursSleep)   : base(firstName, lastName)   {   _avgHoursSleepPerNight = hoursSleep;   }     public int AvgHoursSleepPerNight   {   get { return _avgHoursSleepPerNight; }   set { _avgHoursSleepPerNight = value; }   }     programmer()   {   }   }  

This brings great flexibility to development, especially team development.

Another great point is that many of the base classes and Web controls are inheritable. Therefore, in any language, you can extend them as you wish. A good example of this is the ASP.NET DataGrid control. Say you do not want to use paging, but want to provide a scrollable grid, so browsers that supported inline frames would allow the entire content of the grid to be rendered within a scrollable frame. You can create your own control (say, in Visual Basic), inheriting everything from the base control (perhaps written in C#), and then just output the normal content within an IFRAME. This sort of thing is extremely easy to do with the new framework.

Cross-Language Debugging and Profiling

The cross language debugging features are cool, and provide a huge leap forward over any debugging features we've ever had before. Both the framework and Visual Studio .NET come with visual debuggers, the only difference is the Visual Studio .NET debugger allows remote debugging as well as edit and continue. The debuggers work through the CLR, and allow you to step through ASP.NET pages and into components , whatever the language. Along with debugging, comes tracing and profiling, with the ability to use common techniques to track code.

Both of these topics are covered in detail in Chapter 22.