Migrating large VC++ 6.0 projects to .NET
-
Good people, If anybody seen any links on other good people’s experience on migrating large VC++ 6.0 projects to .NET, could you please send the links to me. Thanks, Serge
-
Good people, If anybody seen any links on other good people’s experience on migrating large VC++ 6.0 projects to .NET, could you please send the links to me. Thanks, Serge
It comes down to how good your programming team is. A lot of stuff that compiled in VC6 does not compile in VC7, because of improvements to the standard adherance. So, if the project is written in good C++, then fine. If the programmers leaned on old VC hacks, then you could have some work in front of you. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
It comes down to how good your programming team is. A lot of stuff that compiled in VC6 does not compile in VC7, because of improvements to the standard adherance. So, if the project is written in good C++, then fine. If the programmers leaned on old VC hacks, then you could have some work in front of you. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Hi Christian, Considering changes to the compiler, I completely agree with your comment; but there’s more than just a compiler: changes in MFC between version 6 and version 7. Just a couple of them to give you an idea on the amount of work when migrating large MFC based projects from VC6 to VC7. 1. Changes in CFile class interface: virtual DWORD CFile::GetLength( ) const; // MFC6 (Visual C++ 6.0) virtual ULONGLONG CFile::GetLength( ) const; // MFC7 (.NET 2003) so that compiling code like this: CFile f; DWORD dwLength = f.GetLength(); will now produce compiler warnings on loosing data; and certainly, this kind of warnings can’t be ignored. Add millions user-defined specialisations of the CFile class in a large MFC based project to complete the picture (actually, it is a good example of when inheritance bites and aggregations should be used instead); 2. Changes in CTime class: in the interface (similar to the 1.) and in size: size of objects of the CTime class is now 8 bytes, instead of 4 bytes; our software serialises objects of the CTime class through sockets; therefore the backward compatibility issue. The change in the CTime class breaks backward compatibility with the legacy systems that can’t be upgraded to run applications built under VC7 with MFC 7; even our non-legacy systems can’t be upgraded in one go, so this backward compatibility issue will exist for a transition period of time. Also consider the backward compatibility requirement (support for both VC6 and VC7 for a transition period of time) so source code now looks like this: CFile f; #if _MFC_VER >= 0x0700 // represents MFC version 7 and later ULONGLONG llLength = f.GetLength(); #else DWORD dwLength = f.GetLength(); #endif and requirements for unit, build, factory etc. testing for two versions - so you’ve got the picture… Serge
-
Hi Christian, Considering changes to the compiler, I completely agree with your comment; but there’s more than just a compiler: changes in MFC between version 6 and version 7. Just a couple of them to give you an idea on the amount of work when migrating large MFC based projects from VC6 to VC7. 1. Changes in CFile class interface: virtual DWORD CFile::GetLength( ) const; // MFC6 (Visual C++ 6.0) virtual ULONGLONG CFile::GetLength( ) const; // MFC7 (.NET 2003) so that compiling code like this: CFile f; DWORD dwLength = f.GetLength(); will now produce compiler warnings on loosing data; and certainly, this kind of warnings can’t be ignored. Add millions user-defined specialisations of the CFile class in a large MFC based project to complete the picture (actually, it is a good example of when inheritance bites and aggregations should be used instead); 2. Changes in CTime class: in the interface (similar to the 1.) and in size: size of objects of the CTime class is now 8 bytes, instead of 4 bytes; our software serialises objects of the CTime class through sockets; therefore the backward compatibility issue. The change in the CTime class breaks backward compatibility with the legacy systems that can’t be upgraded to run applications built under VC7 with MFC 7; even our non-legacy systems can’t be upgraded in one go, so this backward compatibility issue will exist for a transition period of time. Also consider the backward compatibility requirement (support for both VC6 and VC7 for a transition period of time) so source code now looks like this: CFile f; #if _MFC_VER >= 0x0700 // represents MFC version 7 and later ULONGLONG llLength = f.GetLength(); #else DWORD dwLength = f.GetLength(); #endif and requirements for unit, build, factory etc. testing for two versions - so you’ve got the picture… Serge
Oh, OK. I use standard library components where-ever possible, I don't use anything like CArray, or CFile. As a result, I've not been exposed to these sort of problems. I've moved a bit of code from VC6 to VC7, and I only had one problem, and I knew beforehand I would. I once used an iterator as a pointer, which was dumb, but I felt petulant about dereferencing an iterator and then getting the returned item's address, as in &(*it); But you're obviously more exposed to Microsoft changes between versions. I wish you luck :-) Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Oh, OK. I use standard library components where-ever possible, I don't use anything like CArray, or CFile. As a result, I've not been exposed to these sort of problems. I've moved a bit of code from VC6 to VC7, and I only had one problem, and I knew beforehand I would. I once used an iterator as a pointer, which was dumb, but I felt petulant about dereferencing an iterator and then getting the returned item's address, as in &(*it); But you're obviously more exposed to Microsoft changes between versions. I wish you luck :-) Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Thanks!