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 the what .NET Framework is and what 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 impact and 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 and Microsoft essentially ripped up everything and started again but weirdly kept the same basic syntax you’ve been learning in these tutorials.  For the first time ever, in an incredibly brave move, Microsoft essentially said that virtually no existing VB applications could be upgraded and virtually every Visual Basic application out there would have to be rewritten.  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 the BASIC 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 – lots of English language phrases and grammar.  Your computer doesn’t understand English, it understands 0s and 1s.  So when you run your application it has to be translated from the English you’ve types into a language 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 executed.  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 in the .NET Framework, a language that is both fully compiled and interpreted at the same time.  So how did they achieve this?

When you compile a .NET application is 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.

Genius!

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) and it is the CLR that compiles your code from MSIL to 0s and 1s.   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 does this for you now.  The CLR checks to see what variables or objects aren’t in scope any longer and releases them from memory.    When we say object = Nothing, we are saying to the CLR that the Garbage Collector can clear this object 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 get stuck in the next tutorial and delve into these libraries to further enhance our collection class.