Why .NET

Before the introduction of .NET, developing and releasing a product often involved dealing with a conceptual alphabet soup. Microsoft created and encouraged the use of several versions of the Component Object Model (COM), including COM+ and Distributed Component Object Model (DCOM). Using COM, Windows programmers were able to write programs more quickly by relying on a consistent and unified group of Windows services and system resources, such as data sharing and networking support. This, in turn, allowed programs to rely on Dynamic Link Libraries (DLLs), or files that a program would link to access the functionality it needed.

COM, along with Microsoft Foundation Classes (MFC), represented one of Microsoft's first attempts at creating an OOP standard for building Windows applications. MFC provided a way to build modules that utilized basic Windows functionality. COM, in turn, gave programmers the ability to create component libraries made up of code that could be reused by different languages, such as Visual C++ and Visual Basic.

Before the arrival of .NET, distributing a program often meant distributing the DLLs that gave the program the access to services it needed. A game, for instance, might need several DLLs to give it access to high-speed graphics functions. Because DLLs sometimes changed, when programmers were ready to deploy their applications, they would have to consider whether the DLL they were releasing with their product might conflict with a DLL that was already on the user's system. Things would get really complicated if DLLs depended on other DLLs to function.

Unfortunately, with thousands of different software packages and computer configurations to deal with, programmers didn't always get it right. Sometimes the DLLs they installed replaced files that were already on a user's computer with older or incompatible versions of the same files. This often caused other applications on users' computers to mysteriously break. The situation was so common and difficult to deal with that programmers, even those at Microsoft, ultimately began to refer to it as DLL Hell.

Microsoft's solution to DLL Hell was the .NET Framework. The .NET Framework is now responsible for giving Visual Studio programming languages the functionality that they used to get from DLL files. Because DLL files are not needed to develop Windows applications, deployment packages are now a lot smaller. Today, instead of worrying about what version of DLL files users have installed on their computers, programmers need only to make sure that users have the .NET Framework installed.