Blake O'Hare .com

What is .NET? Microsoft Buzzwords Demystified.

There are many things Microsoft has released that are very clear by their name. Internet Explorer. Paint. Word. Windows Update. However, .NET does not rank among them.

In this post, I'll explain what .NET is and a rough overview of how to use it. Many C#/VB tutorials skim over the larger 30,000 ft view of .NET and skip straight to the language itself, leaving many people in the dark to figure out what the buzzwords in Visual Studio mean. This will hopefully serve as a good way to augment such tutorials or just explain what these buzzwords are even if you don't know C# or VB. At the end, I will also go over the other buzzwords you typically hear when you hear ".NET".

As frustratingly vague as this sounds, .NET is a "developer workflow". It's not a programming language simply because it includes several programming languages. It includes a framework that supports the compilation of these languages into a common format such that they can all interop seamlessly (if you're lucky) with each other. There isn't really anything else that specifically does all this, so there's no good word for it. Aside from "Developer Workflow" of course. The best word/phrase I can think of that is accurately descriptive is "a big sticky ball".

Many programming languages compile into some intermediate format. If you're a C programmer, you're familiar with .obj files before you get an .exe file. Languages that are ".NET languages" compile to a thing called the Intermediate Language (IL). It doesn't matter which language was compiled, the IL for each is just the same. IL generated from C# code will work with IL generated from VB.NET code.

Dynamic Link Libraries

Before continuing, you should probably know what a DLL file is. If you already know what it is, then you can skip the next paragraph.

There are very few Windows programs that are EXE's that don't require certain DLL's to run. If you dig around your Program Files folder, you'll see them all lurking about near the exe they are used with. DLL's and EXE's are both files that contain executable code. However, the DLL cannot be started. They are helpers for the EXE which would not work without them. The beauty of DLL's is that they can be used by different EXE files and they are a good way to enforce proper separation of code, to a degree.

EXE's and DLL's typically fall into two varieties: native code and .NET assemblies/executables. .NET executables and assemblies can reference each other very easily without much voodoo, if any. For something to reference a native assembly, you need to use something called COM. This is generally rare.


All you need to know about COM is that it's the thingy that lets you reference native compiled assemblies from other code. COM is often a pain in the.

.NET Projects and Solutions

There are many things that are part of the .NET developer workflow. However, at the root is the notion of building a project.

A .NET project is the smallest unit that can be compiled. When a project is compiled, it will either create an assembly (DLL file) or an executable (EXE file). A project is associated with just one language, such as C#. In it, there is a list of dependencies on the things required to build this project. It can either be a series of core .NET assemblies (the pre-built that comes with .NET that's there for you to use), or a list of other projects that this project depends on, or a file reference directly to another DLL file. It also contains a list of all the files in the project (code or resources), either by calling them out specifically or via wild card.

A solution is a file that contains a list of projects. Typically when you build your projects using either msbuild directly or via an IDE, you build the solution, which in turn compiles each of the projects included in the solution in their dependency order.

That's really all there is at the core of creating .NET applications. There are, however, some buzzwords you may have heard. As promised, here is a quick overview of some of them.


Silverlight adheres to this workflow identically for the most part. In fact, Silverlight assemblies can be referenced by regular client windows .NET projects (the converse is not true for partially obvious reasons). The main difference is that the core assemblies of Silverlight are much watered down than the windows ones since the Silverlight installer size ought to be very small. Silverlight also runs in a trusted mode in a browser sandbox. Running compiled windows code would be dangerous, and also non-sensical on say, a Mac. The other big difference is that Silverlight does not make exe's, obviously. It creates what's called a XAP file which is just a ZIP file with a different extension. The main executable is actually just a DLL. There is a file in the XAP file called AppManifest which dictates which DLL contains the class that gets constructed first. Typically this will be a predefined class called "App" which kicks off the construction of the root visual element and then you have a pretty box in your browser.

Silverlight is the basis of creating Windows Phone apps.


This is simply a subset of the built-in .NET libraries that you may reference from your projects. WinForms is just the collection of classes that are used for creating traditional Windows UI. Simple as that. If you are familiar with Java, this is Swing.


This stands for Windows Presentation Foundation. This was created with .NET 3.0 and was intended to replace WinForms. It, too, is just a subset of the built-in .NET libraries. It allows you to create less traditional Windows UI, typically graphically heavy apps that don't have a custom renderer. (Games for example, will have a custom renderer where a bitmap is drawn to rather than building the UI with windows buttons and scrollbars, etc)


XNA is a specific project type. It creates something that can be deployed onto an XBox, plain and simple. Large portions of the XNA libraries have been ported to the Windows Phone version of Silverlight, which is what most render-heavy games for the Windows Phone are written in. When I say render-heavy, I mean things like Angry Birds and exclude things like Sudoku puzzles.

Those are the big buzzwords. If you hear others and are curious what they are, feel free to add it to the comment thread and I'll throw up a quick definition/explanation on here.