.NET
Colin Fahey
1. Definition of .NET
The term ".NET" refers to the following collection of technologies:
(1) Framework Class Library (FCL)
(2) Intermediate Language (IL)
(3) Common Language Runtime (CLR)
1.1 Framework Class Library (FCL)
The Framework Class Library (FCL) is an extensive set of classes to support:
* containers (Array, String, List, ...)
* multithreading (threads, thread pools)
* networking (sockets, protocols, clients, servers)
* file operations
* data streams
* parsing (regular expressions, XML handling)
* math operations
* exception handling
* language features (reflection, stack trace, dynamic code)
The Framework Class Library (FCL) is implemented for many different platforms ( Windows, Linux, MacOS, ... ).
Thus, a single program which uses the Framework Class Library (FCL) can be developed without significant knowledge of the differences between target platforms.
The Framework Class Library (FCL) contains useful models of fundamental concepts of computer science (such as "thread", "socket", "stream", etc).
In a sense, the Framework Class Library (FCL) gives each supported operating system a modern, high-level, consistent programming interface.
The Framework Class Library (FCL) is one of the most advanced, comprehensive, uniformly-designed, well-documented collections of functions and data types available to programmers.
Unfortunately, the following multimedia aspects are not part of the Framework Class Library (FCL): audio recording, audio playback, video recording, video playback, 3D rendering, joystick input, device control ( CD/DVD, ... ), etc.
Microsoft has a .NET version of the DirectX libraries for their Windows operating system.
There are C# wrappers for OpenGL, OpenAL, GLUT, SDL, etc, but this is not quite as convenient as having such multimedia functions be included in the core Framework Class Library (FCL) and included in the end-user "run-time" libraries.
One of the problems of developing programs that use particular libraries is that the intended set of end-users will require support for the selected libraries.
If it is not convenient to download and install necessary libraries, an end-user might choose to not use a program requiring those libraries.
An end-user might also be reluctant to wait for a library to download from an online location.
If a program developer requires an end-user to find, acquire, and install libraries, all without assistance from a particular program, then the end-user might choose to not use the program.
For example, many open-source projects require end-users to find, download, and install, many different libraries from other open-source projects (examples: openssl, zlib, libpng, libjpg, glut, ...), which is time-consuming, complicated, frustrating, and might result in end-users choosing to search for alternative programs or products.
The "Windows Update" service apparently helps deploy version 1.1 of the .NET run-time libraries to Windows users.
These run-time libraries are included with the Windows XP operating system.
Therefore, creating Windows programs which require .NET 1.1 seems entirely reasonable.
Also, the run-time libraries for Microsoft's implementations of the .NET Framework Class Library (FCL) may be freely redistributed, so that developers can supply these libraries to end-users who do not already have the libraries.
The Windows Vista operating system ships with the .NET 3.0 run-time libraries (a combination of the .NET Framework Class Libraries and several new libraries such as the "Windows Presentation Foundation" (WPF)).
Therefore, deploying .NET 2.0 and .NET 3.0 programs for Windows Vista does not require the installers for the .NET run-time libraries.
1.2 Intermediate Language (IL)
The Intermediate Language (IL) is a small set of simple, processor-independent, operating-system-independent instructions that are sufficient to completely express the data structures and functions of many different high-level programming languages ( C++, C#, F#, Visual Basic, Java, Ocaml, ... ).
Source code written in a high-level language can be compiled down to a corresponding "Intermediate Language" form.
Code in an "Intermediate Language" form can easily be combined with other code in an "Intermediate Language" form.
A computer program (also named "software") can include source code written in several different high-level languages (e.g., C#, C++, and Visual Basic).
All source code can be compiled (converted) to an "Intermediate Language" format to allow easy combining with other compiled code.
Programs in an "Intermediate Language" form is usually converted to machine-specific instructions (e.g., CPU instructions) very shortly before execution (e.g., "Just-In-Time" (JIT) conversion of IL to CPU instructions).
But a program may also be executed in the context of a Virtual Machine (VM) designed to interpret Intermediate Language (IL) instructions.
Code written in various high-level languages ( C#, F#, Ocaml, C++, Visual Basic, ... ), can be compiled to Intermediate Language (IL) form using an appropriate compiler on any supported platform ( Windows, Linux, MacOS X, ... ), and the resulting file, with embedded Intermediate Language (IL) code, is platform-independent and can execute on any platform having an implementation of the .NET Common Language Runtime (CLR).
The Intermediate Language (IL) code generated by the compiler is essentially independent of the platform on which the compiler was executed.
1.3 Common Language Runtime (CLR)
The Common Language Runtime (CLR) is the mechanism responsible for executing code submitted in the Intermediate Language (IL) form.
The Common Language Runtime (CLR) offers various services.
The Common Language Runtime (CLR) may convert Intermediate Language (IL) code to instructions that are native to the platform (e.g., CPU instructions).
The conversion from the Intermediate Language (IL) to platform-specific (e.g., CPU-specific) instructions may happen in advance of any execution (i.e., an "Ahead-Of-Time" (AOT) conversion), or may happen gradually, as the program executes (i.e., "Just-In-Time" (JIT) conversion).
The Just-In-Time (JIT) conversion can use evolving statistics about program execution to dynamically optimize the converted code (example: identifying frequently-used loops and branches, and optimizing them according to observed behavior (which itself depends on current data and events)).
The Common Language Runtime (CLR) manages allocated memory on behalf of the program.
Therefore, the CLR ensures that the program does not fail to access allocated memory while references to such memory persists, and ensures that memory allocations are cancelled, and that memory is made available again for future allocations after the program disposes of all references to such allocations.
The Common Language Runtime (CLR) detects when the program no longer has a reference to a memory allocation, and the memory allocation is marked for deallocation.
The Common Language Runtime (CLR) uses any of a variety of "garbage collection" algorithms (example: "mark-and-sweep") to identify and reclaim memory blocks no longer accessible by a program.
The Common Language Runtime (CLR) handles program exceptions.
The Common Language Runtime (CLR) enforces security policies.
The Common Language Runtime (CLR) uses the "P/Invoke" mechanism to load platform-specific libraries and invoke (call) functions within those libraries.
2. .NET ( FCL, IL, CLR ) implementations by Microsoft
2.1 Introduction
The .NET paradigm ( FCL, IL, CLR ) has been implemented by Microsoft.
The latest version, "3.0", was released in 2006.10.
.NET 3.0 is composed of the .NET 2.0 Framework Class Libraries and several new libraries, such as the "Windows Presentation Foundation" (WPF) associated with the "Silverlight" (formerly WPF/E, formerly Sparkle, ...) browser plugin for Firefox and Internet Explorer.
Microsoft divides the .NET 2.0 software in to two different packages:
(1) .NET Framework Version 2.0 Redistributable Package
The redistributable package is required by end-users to execute programs built for the .NET paradigm. This package must also be installed by developers prior to installing and using the .NET Software Development Kit (SDK) mentioned below.
(2) .NET Framework Version 2.0 Software Development Kit
The software development kit (SDK) is required by developers to compile C# source code to Intermediate Language (IL) program files.
This package contains various development tools and documentation.
2.2 .NET Framework Version 2.0 Redistributable Package
The redistributable package is required by end-users to execute programs built for the .NET paradigm.
This package must also be installed by developers prior to installing and using the .NET Software Development Kit (SDK) mentioned below.
The following Internet page is the main .NET download page:
The section named ".NET Framework Version 2.0 Redistributable Package" has links for three hardware platforms: "Download x86 version", "Download x64 version", "Download IA64 version".
For example, following the link "Download x86 version", leads to a page entitled "Microsoft .NET Framework Version 2.0 Redistributable Package (x86)"
(File Name: dotnetfx.exe; Version: RC1; Date Published: 3/22/2006; Language: English; Download Size: 22.4 MB)
Locally cached version (only for reference; potentially obsolete):
( The file name has been changed here from the original file name of "dotnetfx.exe" to avoid confusing it with the version 1.1 installer also named "dotnetfx.exe". )
2.3 .NET Framework Version 2.0 Software Development Kit (SDK)
The software development kit (SDK) is required by developers to compile C# source code to Intermediate Language (IL) program files.
This package contains various development tools and documentation.
The following Internet page is the main .NET download page:
The section named ".NET Framework Version 2.0 Software Development Kit" has links for three hardware platforms: "Download x86 version", "Download x64 version", "Download IA64 version".
For example, following the link "Download x86 version", leads to a page entitled ".NET Framework 2.0 Software Development Kit (SDK) (x86)"
( File Name: setup.exe; Version: 2.0; Date Published: 11/7/2005; Language: English; Download Size: 354.0 MB )
Locally cached version (only for reference; potentially obsolete):
( The file name has been changed here from the original file name of "setup.exe" to avoid confusing it with all other installation files named "setup.exe". )
3. Microsoft Visual C# : an Integrated Development Environment (IDE) program
3.1 Introduction
An Integrated Development Environment (IDE) program enables a developer to edit source code and execute various tools (examples: compiler, debugger, ...) within the context of a single, unifying program, filled with useful visual indications and controls.
"Microsoft Visual C# 2005 Express Edition" is a no-cost (no payment required) IDE available for download from Microsoft.
For non-database development, it is almost impossible to distinguish this no-cost product from the retail counterpart, "Microsoft Visual C# 2005".
I frequently use both products, professionally and recreationally, and I haven't yet noticed any practical difference between the products.
3.2 Official links
The Internet site's main page:
The page regarding "Visual C# Express Edition":
Click the "Download Now" button on the right side of the page to choose a download option.
( One method is to launch an installer program which will download files from Microsoft during each installation.
A second method is to download a full CD-ROM "ISO" image, which allows future offline installation.
The ISO image, "VCS.iso" ( 451,837,952 bytes; CRC 55884F2C ) for 32-bit x86 English, may be burned to a CD-ROM using "Nero 7 Ultra", for example. )
4. .NET ( FCL, IL, CLR ) implementation by the Mono Project
4.1 Introduction
The .NET paradigm ( FCL, IL, CLR ) has been implemented by participants in a group known as the Mono Project.
4.2 Official links
Project site:
Software download page:
4.3 Locally cached version
Locally cached version of the installer (only for reference; potentially obsolete):
4.4 .NET 2.0 development with Mono
The "mcs" compiler, and the documentation, as of November 2006, mostly pertain to C# 1.0 and FCL 1.1.
However, the "mcs" compiler is able to compile C# 2.0 code that does not contain generics or generic-based features, but limits the API to 1.0.
To do full C# 2.0 development, with FCL 2.0 libraries, use the "gmcs" compiler.
See the following page on the Mono site:
5. SharpDevelop : an open-source Integrated Development Environment (IDE) program
5.1 Introduction
An Integrated Development Environment (IDE) program allows a developer to edit source code and execute various tools (examples: compiler, debugger, ...) within the context of a single, unifying program, filled with useful visual indications and controls.
SharpDevelop is an excellent, open-source IDE program for C#/.NET development.
This IDE closely resembles the Microsoft Visual C# IDE, and, in some respects, the SharpDevelop IDE has improved upon the Microsoft product.
However, Microsoft Visual C# has some features (example: debugging) that the SharpDevelop program does not have (at the time of this writing).
5.2 Official links
The simple Internet site main page:
The page regarding "The Open Source Development Environment for .NET":
The download page, which has details about the 1.1 and 2.0 versions of SharpDevelop:
5.3 Locally cached version
Locally cached version of the installer (only for reference; potentially obsolete):
6. Useful C#/.NET/IL tools
6.1 SciTech Software ".NET Memory Profiler"
This profiler shows memory allocations, and other resource allocations, that a compiled .NET program or assembly makes while executing.
The real-time graph enables a person to see, in detail, how actions of the program (such as actions triggered by user input or other events) affect memory allocation and garbage collection.
The real-time table listing view enables a person to learn details about memory allocations.
This profiler instantly, and dramatically, revealed wasteful memory use in a real-time Direct3D program I had developed.
A pattern of upward ramps and sudden drops (due to "garbage collection") in the memory usage graphs matched perfectly with periodic, very-brief pauses in the 3D drawing of my program.
The profiler enabled me to discover that frequent allocation of temporary objects was accumulating a lot of memory, triggering garbage collection frequently, and taking enough time for each garbage collection to cause a few drawing periods to be missed.
The profiler's real-time table of allocated object types revealed the types of objects which consumed the most memory, and which allocations consumed memory at the highest rate (bytes per second), and which allocations had the highest disposal rate.
Studying the real-time graphs, and the real-time tables, enabled me to focus on studying the way in which certain data types were being used in my code.
Modifying code to avoid frequent allocations of temporary objects can greatly reduce the overall rate of memory allocation and disposal, and can therefore reduce the frequency of garbage collection triggering.
( I believe "Bytes/sec" is a very revealing statistic for real-time memory use, in addition to "Live instances".
) Seeing all of these being updated very rapidly in a table format, and being able to choose how rows are sorted, and changing the sorting parameter at any time, makes the experience of studying a real-time program very engaging and informative.
Memory allocation responses to user interaction with a running program can be studied, and the testing can rapidly adapt to the feedback to narrow down the most-interesting aspect.
( For example, the 2006 July version had the following attributes: version 2.6.89; 4.3 MB; USA $127.00; Download 14-day-limit version, at no cost, for evaluation. )
6.2 FxCop : .NET code analyzer / critic
FxCop analyzes a compiled .NET program (or compiled assembly) and generates a report listing possible problems with the original source code.
Possible performance problems and security problems are identified.
Possible coding convention violations are identified.
FxCop does not require access to the original source code to perform the analysis.
Only the compiled .NET program (which contains IL) is required.
Nonetheless, the FxCop report offers hyperlinks to specific line numbers in the original source code.
If the Microsoft Visual C# 2005 IDE is active, clicking on the hyperlink in the FxCop report will cause the IDE to warp to the relevant source file and line number.
FxCop has, in my opinion, a rather awkward way of integrating with the Microsoft Visual C# 2005 IDE.
However, once it is set up, FxCop produces a very interesting and potentially-valuable report.
The report contains detailed advice on how to improve the original source code.
I think it is worthwhile to analyze a program using FxCop on a periodic basis.
I wouldn't be surprised if some software development projects or businesses required all code written by developers to yield no warnings or criticisms by FxCop.
Rules can be added or removed from the FxCop database, according to needs.
FxCop is an open-source, free program.
6.3 "Reflector for .NET" : decompiler / analyzer
From Lutz Roeder's Internet site:
"Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."
"Reflector" can help a person study how third-party libraries are written.
Sometimes it would be very useful to know exactly how a method in an assembly is implemented.
If a method behaves in an unexpected or mysterious manner, then "Reflector" can be used to see the implementation.
By seeing the implementation, the programmer can work around problems caused by specific implementations of library methods.
A friend told me that "Reflector" helped him learn more about the behavior of poorly-documented methods in the Microsoft implementation of the Framework Class Libraries (FCL).
"Reflector" might be helpful when documentation for a library method consists of only a few words, such as "sets the value" or "event handler".
If a library function invocation is failing for an unknown reason (when all the parameters seem valid), then using "Reflector" to look at the implementation of the library function might reveal the reason for the failure.
"Reflector" performs some "reverse engineering" of a .NET program or assembly.
Other utilities, possibly including "Reflector" itself, can yield source code for programs or assemblies built based on obfuscated source code.
This is obviously a source of concern for some developers and their investors.
( 2006 July: Reflector.zip was version 4.2.45.0 )
7. Internet discussion forums
Google searching is the best way to find answers to specific questions on any subject, but the sites below repeatedly appear in search results for C# and .NET questions.
The sites below are awesome for exploring the many cool things people have done with C# and .NET.
"The Code Project" site has thousands of interesting and useful articles, for C#, C++, and other languages and programming paradigms.
The "MSDN Code Gallery" site has many interesting articles and code samples related to Microsoft technologies.
Other Internet sites related to C# and .NET:
8. General notes
8.1 Platform independence
The Intermediate Language (IL), like Java "byte code", is platform independent.
Any .NET-compliant compiler will generate platform independent Intermediate Language (IL) code to form programs or assemblies.
Programs packaged as executables ("*.exe" files) must have some platform-dependent code specific to an operating system, for the purpose of being properly interpreted and launched as executable software in the context of the particular operating system.
However, the native executable portion of the software file only serves to invoke the .NET CLR engine, submitting the IL code contained within the software file for execution by the CLR engine.
Microsoft offers an implementation of the .NET utilities (compiler, ...), and an implementation of the Framework Class Library (FCL), only for the Windows operating system.
The Mono Project offers implementations of the .NET utilities (compiler, ...), and implementations of the Framework Class Library (FCL), for the following operating systems: Windows, Linux, MacOS X, and BSD.
8.2 Speed compared with non-CLR C/C++
The Common Language Runtime (CLR) aspect of .NET is the context in which a C# program executes.
The CLR performs "garbage collection" and enables programs to invoke functions in "unmanaged" libraries (all of the libraries not implemented in Intermediate Language (IL)).
Any function the does more than pure math, pure string manipulation, or pure memory copying, will invoke functions in "unmanaged" libraries.
All file operations, socket operations, drawing operations, input operations (mouse, keyboard), output operations (console), platform thread operations, precision timer operations, windowing operations, etc, will invoke functions in "unmanaged libraries".
Unfortunately, the mechanism of invoking "unmanaged" functions from the CLR requires a significant amount of time.
Therefore, the overall speed of a program executing in the context of the CLR is noticably slower than a program that can invoke "unmanaged" functions directly.
For certain kinds of software, speed can be important.
For certain kinds of software, speed can make an important difference in the subjective or psychological experience for a person using the software.
For certain kinds of software, speed can make the difference between achieving a goal and failure.
Multithreading, increasing CPU speeds, and improvements to the CLR code generating facility, will help software executing in the context of the CLR execute faster.
However, any code that executes outside the CLR, and invokes platform libraries directly, will inevitably execute significantly faster than the software that executes within the context of the CLR.
The assurances made by the CLR to C# software, such as safely bridging the gap between managed code and unmanaged code, comes at a cost that is unlikely to be reduced.
Therefore, any program that is very platform intensive (examples: 3D simulation or game, file processor, network server, etc) is likely to execute an order of magnitude faster outside the CLR than when executed within the CLR.
The difference is huge.
Also, any program that performs a significant amount of low-level manipulation of data will execute significantly faster outside the CLR than within the CLR.
Programs executing in the context of the CLR execute quickly enough to be useful for many practical purposes.
As CPU speeds increase, and as code takes better advantage of multiple CPUs, programs executing in the context of the CLR will be able to be used for more tasks that require a high rate of computation.
However, in the middle of 2008 the CLR is still not appropriate for 3D games of any sophistication, unless a very aggressive effort is made to reduce the number of function calls to the 3D library (OpenGL or Direct3D), possibly by using concepts such as "shader programs" and "display lists"; anything to reduce the number of function calls.
