Code-reuse is the most sought after feature in the programming world today. The idea is to separate the code into individual components to make it available for other applications to use. This is the main reason the concept of components has been around for many years in different forms. Instead of writing one big monolithic whole software programmers preferred to divide the code into smaller units each of which had a well-defined behavior. 

.Net proposes a new approach to code reuse. It has taken some concepts from its predecessors viz:- DLLs, COM, and COM+ who also follow the concept of code reuse.

In the early days of programming if a developer wanted to use a function library in a program, he compiled the client portion of his program to machine code and then relied on the linker to join this machine code with the library’s object file into a single executable. Here Storage space was wasted because separate executables referencing the same class library would each have separate, unused copies of the class library embedded within them. A second disadvantage was that if a bug was found the whole thing had to be re-compiled and re-distributed.

Due to the storage space disadvantage the DLLs came into picture. With dynamic-link-libraries, executables could share copies of function libraries between them. A developer could simply place an exe file into the same folder as the library file that it referenced and rely on the operating system to do the linking at run-time. This saved space as well as only DLLs could be independently re-compiled and re-distributed.

DLLs faced one problem: only those exes and DLLs written in the same language could be used together. If you write a perfect component in Visual Basic there should be no need of writing it again in VC++. That would be a waste of time.

COM solved the problem. With COM an exe written in Visual Basic or Visual C++ could use a DLL written in Delphi. COM imposed a binary standard. Under this standard, components communicated with each other via interfaces. COM identified interfaces via Globally Unique identifiers. Components were registered in the system registry. The benefit of registering was that it was very easy to see what components were available on one machine. With COM it became easy to write a component in any of the languages supporting COM and to call it from other languages. But this ease was topped up with complexity. COM was difficult to learn. Moreover storing information about all components in the registry made the process of installing software quite complex.

Both COM and DLLs faced a major problem, the well-known “DLL Hell” problem. DLL Hell is a name given to the situation when a compatibility problem arises between different versions of DLLs. It occurs because components always get improved. The idea up to now has been that when we improve a component, we have to make sure that it is compatible with previous versions of a DLL. For this we have to make sure that the Function and method signatures remain same, their functionality remains same. Unfortunately as a component gets more complex it becomes very difficult to maintain backward compatibility. When a new version is installed a program using the older version stops working due to lack of compatibility .Net comes in here. A .Net component is a unit of code reuse. A .Net code is nothing but an Assembly. An assembly can be a single file or can contain number of files. When we compile a C# code the compiler produces an intermediate language. This intermediate language is packed into an assembly. The same happens when we compile to a library.