Microsoft .NET is definitely an improvement over COM technology and is more compact. It brings us nearer to true code reusability. However, many organizations have probably invested huge amounts in building COM components in the last decade. So you may be looking at a great need for migrating existing applications into the .NET Framework. Which application should you consider? All? Some? This tip, excerpted from InformIT, discusses some qualifiers for which to move and which not.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Many organizations have probably invested huge amounts in building COM components in the last decade. COM has been in the market for almost 8 years now. Also, the last decade saw a substantial growth of the information technology (IT) industry in various segments, which means that there has been a lot of code packed in the form of components. So, it is impracticable to rewrite the entire code into .NET components, however good the components may be for designing more robust applications. Existing applications using COM components have already been tested, and a shift to .NET components would mean that this testing would have to be performed against the newly developed applications again. So, there is a great need for interoperability between the COM and .NET components.
However, there are scenarios wherein we need to consider existing applications to be moved to .NET. Let's presume that a method call in our applications only sets a value of a certain property or does reasonably a small amount of work; then the overhead of interoperability would be bit heavy. Usually, the overhead of calling from managed code to unmanaged code via .NET COM interoperability options is insignificant. In cases where there is an intensive usage of Get and Set methods it's better considering rewriting of the application using any of the .NET compliant languages rather than choosing interoperability; otherwise there would heavy performance penalties.
With Visual Studio .NET the development, maintenance and deployment of applications becomes much easier and faster. As such, the .NET development environment is a notable improvement over the COM-based development model for writing distributed applications. If most clients of your existing components will be written in managed code, you should consider either migrating your component to managed code or writing a managed wrapper around it.
There are certain other things that you need to take into consideration while migrating applications to .NET. Most of these things vary from case to case. However, there are obvious things that can be discussed in general. One is choosing an operating system. The choice of an operating system will affect the migration strategy to be followed. Choosing an operating system like Win 2000, Win XP, or Windows [Server 2003] can reap maximum benefits of the .NET Framework. Although the .NET Framework works on Windows 98, Windows NT, and Windows ME, these platforms don't offer complete access .NET features. So the choice of operating systems should go along with the migration plan.
The object-oriented features available in .NET also make it a favorite choice of many designers to consider moving their existing applications to .NET. The reliance of .NET on open standards such as CLI, XML, and SOAP and rich enhancement to the ASP model also makes it a good candidate for migrating existing applications to .NET. Knowing about code reusability and COM interoperability for migration to .NET is of special importance because it not only helps developers decide how to migrate, but it also helps designers and architects deliver better extensible, integral, and interoperable systems.
To read the entire article from which this tip comes, click over InformIT. You have to register there, but the registration is free.