Migrating to the Microsoft .NET Framework

The Microsoft .NET Framework and the common language runtime (CLR) provide new features for creating powerful business applications efficiently and effectively. This section discusses some of the features of the Microsoft .NET Framework and the CLR, and how to take advantage of these features for code migrated from UNIX.

Microsoft .NET Framework

The Microsoft .NET Framework is a set of software integration technologies based on industry standards such as XML, SOAP, and Web Services. A development environment for .NET is Visual Studio .NET, a comprehensive tool set for building and integrating interoperable applications and XML Web Services.

Microsoft .NET provides a number of features that developers can use during or following the migration of an application from UNIX. These include:

• Extensive support for scripting languages. This includes ECMA Script (Java Script) and VBScript. For example, Visual Studio .NET provides support for the integration of C# and Visual Basic .NET in the scripts for Active Server Pages (ASP.NET). This not only increases the performance of the ASP.NET server pages, but also allows for debugging with the same debug session as conventional languages.

• Multiple language support. The .NET Framework is language independent, enabling developers to use the same integrated development environment (IDE) and the same facilities whatever language they are writing in, including C, C++, and Fortran.

• Broad range of platforms. Using the Microsoft .NET Framework broadens the scope for platforms available to run code migrated from UNIX. A version of the .NET Framework (Compact .NET Framework) allows most managed code developed for Visual Studio .NET to run on Windows CE devices. This includes a broad range of devices ranging from embedded controls to the Pocket PC.

(For complete information on all the features available with Visual Studio .NET and the .NET Framework, see the MSDN Web site, www.msdn.microsoft.com.)

This section focuses on how Visual Studio .NET can be used to enhance and expand the functionality of an application migrated from UNIX.

The common language runtime (CLR) works with .NET to provide additional features, as described in the following section.

Common Language Runtime

The common language runtime (CLR) is a cross-platform run-time environment. It compiles multiple languages (including scripting languages) into a binary form known as the Intermediate Language (IL), which the CLR then runs. This allows optimizations for applications to target multiple platforms. Central to the use of the CLR is the principle of managed versus unmanaged code. Managed code runs under the control of the CLR; unmanaged code does not.

If cost reduction is a major business justification for the migration to Windows, using the CLR helps provide additional return on investment in the following ways:

• The CLR and Visual Studio .NET provide powerful tools to make it easier to access the same Windows features that justified the migration to Windows in the first place.

• The CLR provides system-level support for many of the features that a developer would otherwise have to develop.

The CLR provides the following features that are of particular interest for a migration:

• Common data types. This feature allows multiple languages to use and exchange data seamlessly. For example, C or C++ can exchange data with Fortran without special interface definitions in Fortran or C function mappings.

• Unified exception handling. This allows all the .NET Framework languages to use common exception handling routines.

• Cross-language garbage collection.

• Combined managed and unmanaged code in C and C++. This allows the same source program to integrate managed and unmanaged code.

Many languages are supported by the CLR, including C, C++, and C#, which are delivered with Visual Studio .NET. Fortran is available from third parties, such as Lahey-Fujitsu. This provides for multilanguage support from a single IDE. The multiplatform support combined with common data types and exception handling gives developers a powerful tool for building applications.

These features give the .NET Framework combined with Visual Studio .NET many of the integration features with Fortran that would otherwise require an integration strategy during a migration.

(For a complete list of CLR features, see the MSDN CDs or the MSDN Web site, www.msdn.microsoft.com.)

Using the .NET Framework and the CLR with Migrated Applications

The first major step to migrate legacy UNIX C, C++, and Fortran code to the Microsoft .NET Framework is to migrate the code to Windows. Features of the .NET Framework can then be integrated in the code migrated from UNIX.

Following the migration, there are four ways to add .NET and SOAP support to a migrated, unmanaged C or C++ application:

• Use the Microsoft Visual C++ development system SOAP toolkit. Managed code was not available with Visual Studio 6.0; therefore it was bundled with the SOAP toolkit. This toolkit provides the developer with a convenient way to include SOAP support in an application without having to start from scratch with a SOAP parser. This same approach can be used with Visual Studio 6.0 or Visual Studio .NET. For documentation on the SOAP toolkit, see SOAP Toolkit on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/soap/htm/kit_intro_19bj.asp).

• Use CLR p-invoke to access migrated unmanaged code from managed code. This assumes that the unmanaged source is migrated as a DLL. Additionally, unmanaged code can be mixed with managed code by using C++ in Visual Studio .NET.

• Add a COM interface to unmanaged code, which can then interoperate with managed code by using the COM Interop feature of the Microsoft .NET Framework.

• Use Visual Studio .NET C++. By using the Microsoft .NET Framework native support for SOAP in managed code languages, the same C++ program can use both managed and unmanaged code. Source can migrate as is, and then the developer can add functionality for SOAP by using managed code in the same project.

For unmanaged Fortran, the best strategy is to create a C or C++ library for the unmanaged Fortran to call. Then use one of the strategies discussed earlier for integration with C or C++.