问题
I am maintaining a big project (~250k loc, not counting code generated from idl) in Visual C++ 6.0, that uses Visibroker (VB for short) 5.2.1 (which is a CORBA implementation from Borland). Recently, the other module that communicates with my project was upgraded to VB 8.0 and I got a bunch of incompatibility issues. Since VB 5.2.1 is no longer supported while VB 8.0 does not work with Visual C++ 6.0, I am considering migrating the whole project to Visual Studio 2005. It is not a big change like total rewrite large C++ application in C#?, but only resolving all the incompatibility errors.
My question is what kind of strategy should I use to tackle this task? Anyone has done this before? Also, the problem for me is the size of the project. How much effort does it take to do this kind of migration?
FYI, the project has a frontend GUI portion in MFC and a backend CORBA portion. The two are not very well separated though.
Best regards.
回答1:
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.
回答2:
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:
- Breaking Changes VC 2005 - 2008 (VC 2005 -> VC 2008)
- Breaking Changes in the Visual C++ 2005 Compiler (VC 2003 -> VC 2005)
- Breaking Changes in Visual C++ .NET 2003 (VC6 -> VC 2003)
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.
回答3:
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.
来源：https://stackoverflow.com/questions/2974187/migrating-a-big-project-in-mfc-from-visual-c-6-0-to-visual-studio-2005