Visual Basic and the .NET Framework

Now we’re somewhat familiar with the DRY Principle, the Single Responsibility Principle and why we create well designed tiers in our code, it’s time to really delve into what the .NET Framework is and the impact this had on Visual Basic developers back when it was launched.

When Microsoft introduced the .NET Framework in 2002 you wouldn’t believe the controversy it caused with the Visual Basic community.  Visual Basic was the (and I really do mean the) dominant language back in the late 90s/early 2000s.  With the launch of .NET, Microsoft essentially ripped up everything and started again but kept the same BASIC syntax you’ve been learning in these tutorials.  For the first time ever, in an incredibly brave move, Microsoft said that virtually no VB application could be upgraded to the latest version of VB without a major rewrite.  There were literally millions of Visual Basic developers and I wouldn’t like to imagine how many live production mission critical Visual Basic applications.  So what was it about the .NET Framework that broke their Visual Basic apps?  Well other than most of the syntax, just about everything.

The .NET Framework is an enormous library of code for you to tap into and make use of.  It “borrowed” a lot of the concepts of the Java environment which was a major competitor back then.  Java was gaining market share with the “write once, run anywhere” tagline, meaning you could write one Java application and run it on many different operating systems.  Microsoft wanted a piece of that.  Visual Basic 6 was an interpreted language, much like Ruby today, as opposed to a fully compiled language like C++.  The nuances of interpreted languages vs compiled languages are outside the scope of this tutorial but essentially, when you write your code you are writing it in a language you understand i.e. English words and grammar.  Your computer doesn’t understand English, it understands 0’s and 1’s.  So for a computer to run your application it has to translate your code from your English into the 0’s and 1’s that the computer understands.  A fully compiled application is fully translated into a language the computer understands.  An interpreted language is translated one line at a time when the computer executes that line.  Fully compiled languages offer enormous performance benefits over an interpreted language as the translation process happens in one hit.  However interpreted languages are often more flexible, lending themselves to a easier to “write once run anywhere” architecture.  Microsoft, in a stroke of genius, introduced a fully compiled and fully interpreted language called VB.NET.  So how did they achieve this?

When you compile a .NET application it isn’t compiled into machine code there and then.  It is compiled to an Intermediary Language called MSIL (Microsoft Intermediatry Language).  When a .NET application is run for the first time, the MSIL is compiled into full machine code.  There are .NET Frameworks that exist on Unix, Windows, and a number of other operating systems.  If the MSIL is run on a Unix machine with the .NET Framework installed, the MSIL is fully compiled to Unix machine code.  Similarly, if the MSIL is run on a Windows machine with the .NET Framework installed, the MSIL is fully compiled to Windows machine code.  Machine code varies wildly between different operating systems but now, I can write code on Windows, send the MSIL to a user of a Unix machine and it can be run on that environment.

To achieve this, the .NET Framework is essentially a virtual computer sitting on top of your computer.  When you want to draw things on your screen, you aren’t directly instructing your computer to draw, you’re instructing the framework to draw, which in turn instructs the computer to draw.  The computer could be Unix, Windows, Solaris or anywhere where the .NET Framework exists.  The .NET Framework handles everything – memory management, drawing, writing to files or databases.  Everything.  It is a Virtual Machine.   As Java copyrighted the name Virtual Machine, Microsoft couldn’t use it, but the Framework is an entire Virtual Machine sitting on top of your real machine.


When you run your code in the .NET Framework (or to be more correct – when the Framework runs your code) it is run under what is known as the Common Language Runtime (CLR).  It is the CLR that compiles your code from MSIL to 0’s and 1’s.   The CLR also manages the memory to ensure there are no major memory leaks in code.  In the old days memory leaks were a major issue but in .NET, the CLR has a a garbage collector that cleans your applications memory for you.  The garbage collector periodically checks to see what variables or objects aren’t in scope any longer and releases them from memory.    And almost scarily, it does this in its own time.  That’s why Microsoft call .NET code Managed Code – the CLR manages so much for you.

The Framework itself is divided into the following libraries.

These libraries contain other libraries which contain more libraries.   This framework is huge.  The libraries are also identical for C#, VB.NET or whatever other .NET language you prefer to develop in.  For the first time in my life, choosing a programming language was more a case of choosing which syntax you prefer.  None of the .NET programming languages had any real advantage over the other as they are all compiled to the same MSIL and managed by the same CLR.

Blimey!  So what does it all mean?  Let’s delve into these libraries in the next tutorial to see what all the fuss is about.