Recommended migration strategy for C++ project in Visual Studio 6

Question

For a large application written in C++ using Visual Studio 6, what is the best way to move into the modern era?

I'd like to take an incremental approach where we slowly move portions of the code and write new features into C# for example and compile that into a library or dll that can be referenced from the legacy application.

Is this possible and what is the best way to do it?

Edit: At this point we are limited to the Express editions which I believe don't allow use of the MFC libraries which are heavily used in our current app. It's also quite a large app with a lot of hardware dependencies so I don't think a wholesale migration is in the cards.

Edit2: We've looked into writing COM-wrapped components in C# but having no COM experience this is scary and complicated. Is it possible to generate a C# dll with a straight-C interface with all the managed goodness hidden inside? Or is COM a necessary evil?

Answer 1

I'd like to take an incremental approach where we slowly move portions of the code

That's the only realistic way to do it.

First, what kind of version control do you use? (If you use branching version control that allows you to make experiments and see what works, while minimizing the risk of compromising your code; others are OK also, but you'll have to be really careful depending on what you are using).

Edit: I just saw you are using SVN. It may be worthwile to move to mercurial or git if you have the liberty to do that (the change provides a quantum leap in what you can do with the code-base).

and write new features into C# for example and compile that into a library or dll that can be referenced from the legacy application.

That's ... not necessarily a good idea. C# code can expose COM interfaces that are accessible in C++. Writing client code in C++ for modules written in C# can be fun, but you may find it taxing (in terms of effort to benefits ratio); It is also slow and error-prone (compared to writing C# client code for modules written in C++).

Better consider creating an application framework in C# and using modules (already) written in C++ for the core functionality.

Is this possible and what is the best way to do it?

Yes, it's possible.

How many people are involved in the project?

If there are many, the best way would be to have a few (two? four?) work on the new application framework and have the rest continue as usual.

If there are few, you can consider having either a person in charge of this, or more people working part-time on it.

The percentage of people/effort assigned on each (old code maintenance and new code development) should depend on the size of the team and your priorities (Is the transition a low priority issue? Is it necessary to be finished by a given date?)

The best way to do this would be to start adapting modules of the code to be usable in multiple scenarios (with both the old code and the new one) and continue development in parallel (again, this would be greatly eased by using a branching distributed version control system).

Here's how I would go about it (iterative development, with small steps and lots of validity checks in between):

1. Pick a functional module (something that is not GUI-related) in the old code-base.

2. Remove MFC code (and other libraries not available in VS2010 Express - like ATL) references from the module picked in step 1.

   Do not attempt to rewrite MFC/ATL functionality with custom code, unless for small changes (that is, it is not feasible to decide to create your own GUI framework, but it is OK to decide to write your own COM interface pointer wrapper similar to ATL's CComPtr).

   If the code is heavily dependent on a library, better separate it as much as possible, then mark it down to be rewritten at a future point using new technologies. Either way, for a library heavily-dependent on MFC you're better off rewriting the code using something else (C#?).

3. reduce coupling with the chosen module as much as possible (make sure the code is in a separate library, decide clearly what functionality the module exposes to client code) and access the delimited functionality only through the decided exposed interface (in the old code).

4. Make sure the old code base still works with the modified module (test - eventually automate the testing for this module) - this is critical if you need to still stay in the market until you can ship the new version.

5. While maintaining the current application, start a new project (C# based?) that implements the GUI and other parts you need to modernize (like the parts heavily-dependent on MFC). This should be a thin-layer application, preferably agnostic of the business logic (which should remain in the legacy code as much as possible).

   Depending on what the old code does and the interfaces you define, it may make sense to use C++/CLI instead of C# for parts of the code (it can work with native C++ pointers and managed code, allowing you to make an easy transition when comunicating between managed .NET code and C++ native code).

6. Make the new application use the module picked in step 1.

7. Pick a new module, go back to step 2.

Advantages:

• refactoring will be performed (necessary for the separation of modules)

• at the end you should have a battery of tests for your functional modules (if you do not already).

• you still have something to ship in between.

A few notes:

• If you do not use a distributed branching version control system, you're better off working on one module at a time. If you use branching/distributed source control, you can distribute different modules to different team members, and centralize the changes every time something new has been ported.

• It is very important that each step is clearly delimited (so that you can roll back your changes to the last stable version, try new things and so on). This is another issue that is difficult with SVN and easy with Mercurial / Git.

• Before starting, change the names of all your project files to have a .2005.vcproj extension, and do the same for the solution file. When creating the new project file, do the same with .2010.vcxproj for the project files and solution (you should still do this if you convert the solutions/projects). The idea is that you should have both in parallel and open whichever you want at any point. You shouldn't have to make a source-tree update to a different label/tag/date in source control just to switch IDEs.

Edit2: We've looked into writing COM-wrapped components in C# but having no COM experience this is scary and complicated.

You can still do it, by writing wrapper code (a small templated smart pointer class for COM interfaces wouldn't go amiss for example - similar to CComPtr in ATL). If you isolated the COM code behind some wrappers you could write client code (agnostic of COM) with (almost) no problems.

Is it possible to generate a C# dll with a straight-C interface with all the managed goodness hidden inside? Or is COM a necessary evil?

Not that I know of. I think COM will be a necessary evil if you plan to use server code written in C# and client code in C++.

It is possible the other way around.

Answer 2

Faced with the same task, my strategy would be something like:

1. Identify what we hope to gain by moving to 2010 development - it could be

   • improved quality assurance: unit testing, mocking are part of modern development tools
   • slicker UI: WPF provides a modern look and feel.
   • productivity: in some areas, .NET development is more productive than C++ development
   • support: new tools are supported with improvements and bugfixes.

2. Identify which parts of the system will not gain from being moved to C#:

   • hardware access, low-level algorithmic code
   • pretty much most bespoke non-UI working code - no point throwing it out if it already works

3. Identify which parts of the system need to be migrated to c#. For these parts, ensure that the current implementation in C++ is decoupled and modular so that those parts can be swapped out. If the app is a monolith, then considerable work will be needed refactoring the app so that it can be broken up and select pieces reimplemented in c#. (It is possible to refactor nothing, instead just focus on implementing new application functionality in c#.)

4. Now that you've identified which parts will remain in C++ and which parts will be implemented in c#, (or just stipulate that new features are in c#) then focus turns to how to integrate c# and c++ into a single solution

   • use COM wrappers - if your existing C++ project makes good use of OO, this is often not as difficult as it may seem. With MSVC 6 you can use the ATL classes to expose your classes as COM components.
   • Integrate directly the native and c# code. Integrating "legacy" compiled code requires an intermediate DLL - see here for details.

Mixing the MFC UI and c# UI is probably not achieveable, and not adviseable either as it would produce a UI mix of two distinct styles (1990s grey and 2010 vibe). It is simpler to focus on achieving incremental migration, such as implementing new application code in c# and calling that from the native C++ code. This keeps the amount of migrated c# code small to begin with. As you get more into the 2010 development, you can then take the larger chunks that cannot be migrated incrementally, such as the UI.