Why Platform Invoke Interop?

First, you need to preserve your investment. It is a little hard to see in the simple examples in Listings 7.1–7.4, but many companies invest considerable time and money into software. It would be impractical to suggest to management that you want to spend X amount of time porting existing software to a new platform that will have no new features that a customer can see. In some cases, the functionality of the existing software might be so involved and complex that porting it to another language would be the equivalent of rewriting it. The “bean counters” see this as an investment of time and money that has at best no return on investment, and at worst, a negative return. For the most part, the bean counters are right. Being on the latest platform does not count much for the bottom line. However, being able to reuse software is appealing to engineers and accountants alike.

Second, the new platform might offer significant advantages (.NET Framework clearly does), so you would like to begin to take advantage of these features as soon as possible. In the end, you would like to have all of your code under one roof, but for now, you just want to use the old code. In this case, interop gives you the option of phasing in the pieces of your application one at a time. While your new app is generating revenue, your engineers can be working on porting pieces of the old code to the new platform. This might have the added benefit of compartmentalizing your software, making it easier to upgrade and maintain in the long run.

Third, some things do not change. It might be a black box that you cannot change because it is from a third party, you don't have the source any more, the tools are not available that are needed to compile it, and so on.

With interop, you can still use the existing code in a new environment that was not available when the original software was written.