General Migration Strategy to .NET 2.0

We have a lot of legacy C/C++ code that exists in the form

of libraries (in the form of LIB’s and DLL’s) and applications that use these

libraries.

We want to migrate our libraries and applications to the

.NET world.

To maximize code reuse, we would like to migrate our

libraries in the form of managed wrappers so that any .NET language (C++/CLI,

C#, VB 2005 etc) will be able to access their functionality.

However, since we cannot migrate all our applications to the

.NET world at the same time we would like the ability for the legacy native applications

to be able to take advantage of any bug fixes or new features in the new

libraries without having to maintain parallel code bases (one for .NET managed

applications and one for legacy native applications).

Is there a way to migrate our legacy libraries without

having to maintain two code bases with the following properties?

1. Future

   .NET applications written in any .NET language can use them.

2. Current

   legacy applications can use them.

Will the following approach work?

1. Recompile

   every legacy library and application with Visual Studio 2005 to native unmanaged code.We now have new native unmanaged LIB’s, DLL’s (libraries),

   and EXE’s (applications) that have been compiled with Visual Studio 2005.

2. For

   each library, create a new mixed mode (with the /CLR switch) C++/CLI project that will produce a .NET managed

   wrapper version of the library that will be accessible from any .NET

   language.

3. Any

   new application should be written as a .NET application (unless it requires

   the raw speed of native C++ code) and should only use the managed wrapper

   version of the library.

4. We can

   then migrate our legacy applications to .NET as our funding permits.

Our libraries will now exist in the following form:

1. A

   native unmanaged version (LIB’s, DLL’s).

2. A

   managed wrapper version (.NET DLL) that is just a wrapper and all

   functionality depends on the native version.

Applications that have not been migrated to .NET will just

link to the native version of the library.

New .NET applications will use the managed wrapper version.

To provide bug fixes or new features to these libraries, we

should use the following approach:

1. To fix

   bugs or add new features, modify the source code for the native unmanaged library

   and rebuild it.

2. Rebuild

   the managed wrapper library.Since

   it’s just a wrapper, it will automatically use the bug fixes from the

   native library.If a new feature in

   the form of a new function was added to the native library, then you would

   also add a wrapper for this new function to expose to the .NET world.

3. Rebuild

   all applications that use this library.

   If the application needs to call a new function in this library,

   then you would also modify the application to call this new function.

When you reach the point that only managed .NET applications

use this library (in other words, all applications that use this library has

been migrated to the .NET world) then we can consider phasing out the native

library and porting all functionality into the .NET managed wrapper.

Will this work? Is this a good

approach? Is there a better approach? Any suggestions for

improving this approach? Thanks for any comments! :)

[4166 byte] By [BlueBeetle] at [2007-12-22]