We’ve touched upon several aspects of the .NET Framework, along with C# as a language, however we haven’t looked at how these two relate to one another. In most cases, it’s not important to think about all of this when you’re programming. Rather, the point of understanding these details, on a basic level, is to have a working knowledge of how the various aspects of C# and the .NET Framework operate.

At the basis, C# is a programming language that is the foundation for the .NET Framework, which in turn is a library of functionality (pre-built Class Libraries) that you can incorporate into your C# applications. For example, whenever we’re working with ASP.NET-related
classes, we’re incorporating the System.Web namespace containing a plethora of classes related to all types of ASP.NET functionality. You can find these Framework Class Libraries by navigating to the folder that stores the associated .dll files:


One of the reasons for why the Class Libraries are separated into individual .dll files is to reduce performance load, allowing you to choose only the Libraries you need for a particular task.


Note that the System.Web.dll Library is one of the largest in the Framework. It’s been a contention amongst some developers that this is too big for any single Library and should ideally be broken up into sub-libraries. While 5,222KB might not seem like a lot, loading this every time a page runs on a remote Server could represent a significant hit to its bandwidth.

In addition to the Framework Class Library, the .NET Framework also contains the runtime environment known as the Common Language Runtime (CLR). The CLR operates as a protective bubble – kind of like a Virtual Machine – that wraps around your high-level application code and
executes it down at a lower machine-readable level. As the name suggests, this allows for different languages supported by the CLR to essentially become one-and-the-same at the lower computational level. The runtime functionality of the CLR manages low-level interfacing with hardware and memory states, freeing up your resources as a programmer to focus on solving problems having to do with the application’s main purpose.

As a side-note, you might be interested in creating your own custom Class Libraries – boiling-down your code into a .dll Assembly and allowing you to reuse it across various projects. You can compile your project into a Class Library using the csc.exe Compiler found in the
following folder:


This Compiler creates an .exe or .dll .NET Assembily which is comprised of code that’s been compiled-down to what’s called an Intermediate Language (IL). The CLR is then able to run this IL – within the “protected bubble” – when the application is started.


The main difference between.exe and .dll Assemblies is that an .exe has a programmatic entry-point to kick-off and run the code when accessed, whereas a .dll just stores code so that it can be referenced elsewhere in some other code.

It might be helpful to take a look at the ildasm.exe tool, which allows you to disassemble your Assembly back into a somewhat human-readable format:


Running HeroMonster.dll through the ildasm.exe tool, we can see how the code was constructed even after it’s been compiled down into an Assembly:


Looking closer at the Attack() method, we get to peak at the resulting Intermediate Language (IL) that the original code was compiled down to:


Lessons in this Course