Why .NET

Despite its substantial popularity, com suffers from a numbers of limitations.

                       

      .Com itself offered for binary code reuse; it did not offer a model for source code reuse. An implication of this is that, although com offered interfaced-based inheritance. It did not support code-based inheritance.

      Although .com offered the promise of a language independent architecture, reality often fulfill short of the premise. The root of the problem was the fact that seamless interoperability with com presupposed that each language was able to create and manipulate common automation compatible data types. This however was not the case. As a result although com made some real advances in the area of language independence it also had some real weaker ness.

       .Com was extremely complex and for the most part only c++ programmers were able to work with com directly for VB programmers the visual basic failed to give the developer full control over com when it was needed and many visual basic programmers often locked sufficient even of those features that they were able to control.

In addition .com did not offer an integrated class library comparable to the .net FCL. Instead the developers of each application or operating system service were free to implement whatever object model made sense to extend their application. As a result, there are major gaps in the functionality made available through .com automation and there is not a good deal of consistency across object models.

The .NET platform and the .NET framework class library were developed in an effort to address these weaknesses of.com.