What the Microsoft .NET Framework
and Visual Studio .NET
are All About

Michael A. Covington

Artificial Intelligence Center

The University of Georgia


These are some brief notes written to demystify the .NET Framework for my students.

Microsoft has not been particularly good at explaining just what .NET is. Much of their literature gives the impression that it's some kind of extended networking capability.

And indeed the .NET Framework makes it easier to write programs that do sophisticated things with the Internet. But that's far from the essence of it.

So What Is .NET?

The .NET Framework is a radically new API (application program interface) for Windows. That is, it's a new way for programs to communicate with the operating system.
The big change is that now the API is pervasively object-oriented and has a rich system of types. If a system routine needs a list of strings, you can pass it a list of strings - not a pointer to a pointer to a place where there ought to be some characters ending with a double zero byte.
But it's also a radically new way to deploy programs.
The big change is that under .NET, the .EXE files don't contain Pentium machine code! Instead, they contain bytecode (MSIL, "Microsoft Intermediate Language") which is compiled by the computer that's going to run the program, right when it's needed ("JIT" = "just-in-time compilation").

As a result, .EXE files are much smaller. They are also (in the future) much easier to port to non-Pentium architectures.

Motivation for .NET

Why .NET? Several reasons.

Windows programming is unduly difficult.

Since the 1970s, serious programming on small computers has been done in C and has relied heavily on pointers manipulated by the programmer.

This is error-prone even when you don't have to handle windows. If you have a graphical user interface, it gets positively unwieldy.

Windows programming became much easier with the advent of frameworks such as Visual Basic, Delphi, C++ Builder, and Visual C++. But these frameworks are not part of the operating system. They generate rather large .EXE files which call lower-level API functions.

Key idea: Move the Delphi idea into the operating system. Make Windows work like Visual Basic or Delphi (so that they aren't just frameworks running under it).

Windows software is unreliable.
This is largely because so much depends on pointers and memory allocations that are the responsibility of the programmer.

"Memory leaks" are common; many programs fail to release all their memory when they terminate. Addressing nonexistent memory locations is a common cause of program crashes.

Key idea: The programmer should deal with data, not with pointers or memory. Windows memory management should be like Lisp or Prolog, not like C.

DLLs are a real mess!
Subroutines for Windows programs can reside in DLLs (dynamic-link libraries), files which are callable by more than one program. This is a useful feature.

But if two DLLs have the same name, Windows doesn't know which one to use!

This problem is called "DLL Hell" and is surprisingly common. Often, two programs use different versions of a DLL that came with a popular compiler. When you install the second program, the first one no longer works. Misery!

Windows 2000 and XP include some safeguards to make this less likely, but what's really needed is a change in the nature of DLLs.

Key idea: In .NET, all DLLs are uniquely identifiable (even if they have the same names) and no program will ever call the wrong one.

Windows won't always be tied to the Pentium.
We can't go on generating Intel 32-bit (and even 16-bit) machine code forever. Eventually, a new CPU is going to come along, and we'll want to port Windows to it. Do we want to spend our lives accumulating non-portable programs? No.

Key idea: Distribute bytecode (like Java) and do the final compilation on the computer that will actually run the program.

This compiler is very fast, simple, and reliable. It normally compiles "just in time" ("JIT"), so each procedure does not get compiled until the first call is made to it. But you can arrange for the whole program to be compiled at the time of installation.

Windows needs a richer API.
To put it bluntly, Windows needs to provide a greater range of services to programs, including advanced network functionality.

What better place to put it than here?

Making .NET Programs Run on Your Computer

Most .NET programs consist of a single (and surprisingly small) .EXE file. On a properly equipped computer, you can simply copy the file anywhere and execute it.

Almost any Windows PC that has had updates since 2005 or so will already have .NET installed on it.

On computers that are not up to date, you must download the .NET Framework Redistributable from Microsoft (here) and install it on your PC. Later versions of Windows will include it, but right now, if you try to run a .NET program on a PC that doesn't have .NET, you get the infamous message box:

(Think about it: .NET can't give you a meaningful error message because .NET isn't there.)

In our lab, if you develop programs on drive U:, you must also tell .NET that it's OK to execute code on a shared drive. (Click here for information.) Otherwise you'll have difficulty. .NET identifies disks as "trusted" or "not trusted".

If you develop programs with Visual Studio, you can easily generate installation scripts that check for the presence of .NET, and complain intelligently if it's missing, before installing your program.

Note: The .NET Redistributable requires Windows 98, ME, 2000, XP, or later. The .NET compilers and development tools require Windows 2000, XP, or later.

Note: You can and will have several versions of .NET on the same computer. Versions 3.5, 3,0, 2.0, and 1.1 does not replace version 1.0; instead (to avoid "DLL Hell") every .NET program is bound to a specific version.

Programming under .NET

Initially, Microsoft supports three programming languages under .NET: Command-line compilers for these languages are available free from Microsoft. We'll get to Visual Studio in a moment.

C# is more than just Java redone - it preserves some important C++ features such as operator overloading and enumerated types. It might be more correctly described as C++ trimmed down and made more logical.

C# is profoundly similar to Borland Delphi in everything except syntax. You can describe it as a language that looks like C but thinks like Delphi. There's a good reason for this: C# was designed by Anders Hejlsberg, the same man who (at Borland) developed Turbo Pascal and then Delphi. (More of Hejlsberg's comments are here and here.)

Programming in C#

C# is a clean, simple, powerful object-oriented language based on C. It is much simpler than C++ and appreciably more versatile than Java. Here's a tiny program:
class MyProgram
  static void Main(string[] args)
    System.Console.WriteLine("Hello, world!");
    if (args.Length > 0) 
       System.Console.WriteLine("My arguments are:");
       foreach (string s in args)
(For a full tutorial on C#, aimed at people who know some C++ or Java, click here.)

The first thing a C++ programmer will notice, coming into C#, is that there are no pointers. Memory management is like Lisp and Prolog: objects are easy to create, and they are automatically garbage-collected when no longer needed.

(Actually there are pointers. You can declare a section of your program "unsafe" and then manipulate pointers to your heart's content. The "unsafe" declaration tells the garbage collector not to bother it until it finishes executing.)

The second thing you'll notice is that there is a rich variety of data types and in particular that arrays are really lists. Again it's like Lisp and Prolog. You can easily create "jagged" arrays (arrays with unequal numbers of elements in each row).

The third and most unusual thing about C# is reflection: the program has access to a lot of information about itself at run time. It's easy to pass data structures around and then examine them to find out their size and contents. Reflection also makes it easy to generate useful error messages when a program encounters an exception.

Visual Basic and C++ under .NET have most of these special properties as well.

Visual Studio

In the tradition of Visual Basic and Delphi, Visual Studio gives you a graphical environment for designing and testing programs. It supports:

Visual Studio looks like this:

When you place a button on the form and click on it, you get to write the code that will execute when the button is clicked:

All this is familiar. But here are some noteworthy points:

You can change anything at any time. You do not have to do the layout before writing the code.

The whole program is textual. All the attributes of all the windows are expressed in program code (which is generated and updated for you). Nothing is hidden in binary.

Console applications are OK again. Visual Studio isn't just for windowed programs; you can easily write console applications that run at the command prompt. Many UNIX applications are easy to port to Windows in this way.

When you create a project, you create a directory, not just a file. Your program project consists of a collection of files.

Visual Studio gives you lots of help. As you are typing any procedure call, you're shown what arguments are expected, like this:

If you document your own procedures in the standard format, this information will pop up for them too... and Visual Studio can grind out HTML documentation for the whole program!

Web Development

Visual Studio makes it surprisingly easy to develop ASP.NET applications (programs that run on a server and are accessed by web browsers, like Java servlets). An elaborate graphical user interface is available and works much the same way as when developing an ordinary program.

If you want to do this at the AI Center, let me know, because I'll have to set up an ASP-enabled directory on your web site. Please do not run IIS (Internet Information Server) on your own PC, or if you do, let me help you configure it not to accept outside requests.

Interoperability with Prolog

As yet, there is no Prolog for .NET, but implementing it would be a good idea, especially since so much of the memory management is already done.

Meanwhile, .NET programs can call ordinary DLLs, and ordinary Windows programs can call .NET DLLs. So .NET programs should have the same interoperability with LPA Prolog and Amzi Prolog that we have been enjoying with earlier editions of Visual C++.

Recommended Books

I recommend the Wrox Press series of books on .NET and Visual Studio, especially: and their counterparts in VB and C++.

The content and opinions expressed on this Web page do not necessarily reflect the views of,
nor are they endorsed by, the University of Georgia or the University System of Georgia.