Chapter 9. Migrating to Visual C .NET
| Snoops |
 | Migrating to .NET: A Pragmatic Path to Visual Basic .NET, Visual C++ .NET, and ASP.NET By Dhananjay Katre, Prashant Halari, Narayana Rao Surapaneni, Manu Gupta, Meghana Deshpande |
| Table of Contents | |
Chapter 9. Migrating to Visual C++ .NETWhen we say we want to migrate the existing C++ code to .NET Framework, the first question that comes to our mind is What is the need to migrate the existing code to .NET Framework when it supports the interoperability with the existing C++ code? The answer lies in the extent of support provided for the interoperability with existing C++ code, the overhead associated with the interoperability, and the ability to exploit the various features provided by it. We start with the extent of support provided by .NET Framework for interoperability with existing C++ code. There are four aspects to this:
The .NET Framework provides extensive support for all these. However, there are bound to be cases where the features provided fall short of expectations. Let us discuss these. When calling an existing COM component from .NET, the environment provides a straightforward way to do so: generation an RCW . The RCW is generated by the utilities provided with the .NET Framework so that the .NET client can call the COM component. The RCW acts as a proxy between COM and the .NET client. This, however, has the drawback of having significant overhead in terms of performance because for each method call to COM, a context switch is required from .NET code to unmanaged code and vice versa. Consider the case where your .NET application makes a frequent call to the COM component; it may a have high interoperability cost due to the context switch between the two environments. In such a scenario, you have to look into your application requirements, and decide whether such performance degradation due to the interoperability layer of .NET is acceptable or not. If interoperability overhead is unacceptable, you are left with the two options: either go for complete migration of COM or put a wrapper around the COM component and move the frequently called COM methods in the wrapper itself. The next aspect is calling a .NET component from unmanaged code. Again, .NET provides great support in terms of providing every assembly with a COM CCW . The CCW provides a wrapper around the .NET component so that the existing Visual Studio 6.0 applications can call the .NET component as they do other COM component. However, the calls again suffer in terms of performance degradation due to a context switch. Now, we come to the point of invoking unmanaged code API from .NET. Given the amount of legacy code, encountering this scenario would be certain. However, .NET bails us out with P/Invoke. P/Invoke allows us to call the C-style APIs in Win32 DLLs and takes care of data marshalling between managed and unmanaged code. Finally, we come to the existing C++ class. Microsoft .NET provides support for the mixing of unmanaged and managed code with some limitations. Consider the scenario where you want to derive your managed class from the unmanaged class; .NET does not allow you to do this. Take another scenario where you want to pass the managed object to the unmanaged class, which has implemented the copy constructor; again, managed extensions do not support copy constructors for the managed objects. In such scenario, you have to evaluate your application design and make the required modifications so that your existing unmanaged code can be mixed with the managed code. Let us summarize these scenarios. We have selected C++ as a language for our component or application due to its powerful features and the performance provided by it. In general, due to the interoperability layer of .NET, we are compromising the performance. But again in some scenarios, this performance degradation is within acceptable limits, and in other scenarios, we may have to migrate partial or complete existing C++ code. Small applications without much complicated logic could just as easily be rewritten as they could be migrated . The monolithic and/or mission critical applications are the ones that require a lot of care; the viable option in this case would be to migrate in a phased manner. Effort could be spent in migrating portions of it at a time, verifying those changes and then converging to a totally managed code base. This phased approach would have the advantage of allowing the existing code base reliability to be retained and at the same time adding to the lifetime of the application. Decisions might be required to have design and/or technology infusions in terms of upgrading portions of the application to newer technologies. Consider for instance a Web-based application that has an ISAPI running on the server side. An option might be considered where it could be migrated to an ATL Server model or implemented as a Web service. Legacy database applications could be made more robust by exploiting the ADO.NET programming model. This would lend a boost to the maintainability of the application given the ease of coding using it. However, the gains are to be evaluated carefully , considering the investment made in developing the existing code and comparing the effort spent to migrate to the effort to totally rewrite the code. In this chapter we'll discuss the scenarios for migration as well as interoperability and the various issues involved during the process.  |
| Snoops |
| Top |
EAN: N/A
Pages: 149