ansaurus

Question

Migrating a big project in MFC from Visual C++ 6.0 to Visual Studio 2005

Answer 1

A:

How difficult this will be will depend a lot on how well the code is written. If the project has good layering and the CORBA stuff is pretty well encapsulated in libraries and most of the rest of the application logic does not depend on it directly, then it shouldn't be too bad. If the CORBA calls are all over the place interspersed with your application logic then it will probably be harder. But it really depends on the nature of the compatibility issues between the two versions of vb, I'm not familiar with the specific issues. You would think that the vendor would have some documentation on compatibility between the versions and a migration strategy.

bshields 2010-06-04 13:01:27

Answer 2

A:

In theory, you can just open your old project in the new IDE and build it. In reality you will have two issues - the meta files that hold your "here are all my source files and my compiler options" and your actual code: .dsp and .dsw way back when, .sln and .vproj now. The first one may require you to wander through an upgrade process from 6.0 to 7.0 to 8.0 and if you don't want to or can't, you may need to reconstruct that by making an empty solution/project and adding your source files into it and setting your options.

Then you need to deal with any breaking changes in the libraries since you last built. I think this is likely to be the secure CRT changes and the for loop scope. The compiler will find them all for you. You won't much enjoy changing all that, but that's to be expected.

By the way, I would go all the way to VS2010, not to 2005. Buy yourself as long a period of time as possibly before you have to do this again.

Kate Gregory 2010-06-04 13:06:32

"By the way, I would go all the way to VS2010" +1

anno 2010-06-04 13:29:38

-1: for two reasons. The theory that you should just be able to open and DSW int he new IDE and compile does not reflect the reality that porting from VC6 to VC8 can be very difficult. Also, the suggestion that the compiler will tell you everything you need to fix is simply wrong. Just as you can't use a compiler to tell you what is Standards compliant, you can't rely on the compiler to find all your bugs when porting. Ported code may compile, but still not run as intended. You have to understand all the breaking changes, not just compile-and-edit.

John Dibling 2010-06-04 14:18:05

Yes, understand. However, not find. So you should understand the change in loop scope. But you don't have to look at 3,000 for loops to see which ones redeclare the variable afterwards ... the compiler will find those for you.

Kate Gregory 2010-06-04 15:08:34

Answer 3

A:

I adressed porting from VC6 to VC9 in this post. I ported a million-line monolithic app from VC6 to VC9 last year, and it proved to be extraordinarily difficult. VC6 was notorious for being not very Standards-compliant even when it came out, and as the Standard evolved in the following years, VC6's compliance just became worse. Microsoft took the opportunity to fix this problem in VC7 to a large degree, but in doing so broke a lot of code that compiled in VC6.

In some cases the code broke because the code itself was poor, and VC7 was a much better compiler that did not allow many liberties that VC6 did. But in many cases "good code" (from VC6's point of view) became illegal code because of the increased conformance. A very simple example:

for( int i = 0, cont = 1; cont; ++i )
{
  // count something up
}

cout << "The number is now " << i << endl;

This code is perfectly fine as far as VC6 is concerned, but according to the Standard i falls out of scope at the end of the for block. There are many, many other examples of things like this that changed from VC6 to VC7 (and from VC7 to VC8 etc). You should review these changes carefully before you proceed:

We had many compelling reasons to move to VC9 beyond just better compliance. One was the ability to compile 64-bit apps, and so we eventually decided to port the entire app. But you may have alternatives.

If the compiler is creating a roadblock for you in just one portion of the code, you might consider porting just that portion, and creating a layer compiled in VC9 that bridges the gap between VB 8.0 and your VC6 application. This could be little more than a marshalling proxy, that does nothing more than move data between your main application and the 3rd-party component.

John Dibling 2010-06-04 14:01:16

ansaurus

tags:

views:

answers:

Migrating a big project in MFC from Visual C++ 6.0 to Visual Studio 2005

related questions