我在Visual C++ 6.0中使用Visibroker（簡稱VB）維護一個大項目（〜250k loc，不包括idl生成的代碼）。 1（這是Borland的CORBA實現）。最近，與我的項目進行通信的其他模塊已升級到VB 8.0，並且遇到了一系列不兼容問題。由於VB 5.2.1不再支持，而VB 8.0不適用於Visual C++ 6.0，因此我正在考慮將整個項目遷移到Visual Studio 2005.它不是像total rewrite large C++ application in C#?那樣的大變化，而只是解決了所有不兼容性錯誤。將Visual C++ 6.0中的大型項目從Visual C++ 6.0遷移到Visual Studio 2005
我的問題是我應該用什麼樣的策略來解決這個任務？任何人都曾經這樣做過？另外，對我來說問題在於項目的規模。做這種遷移需要多少努力？
僅供參考，該項目在MFC中有一個前端GUI部分和一個後端CORBA部分。雖然這兩者分離不是很好。
此致敬禮。
這將是多麼困難將取決於代碼編寫的程度。如果項目具有良好的分層，並且CORBA的東西在庫中很好地封裝並且大部分其他應用程序邏輯不直接依賴它，那麼它不應該太糟糕。如果CORBA調用遍佈整個應用程序邏輯，那麼它可能會更困難。但是這實際上取決於兩個版本vb之間的兼容性問題的性質，我不熟悉具體問題。您會認爲供應商會提供一些關於版本與遷移策略之間兼容性的文檔。
理論上，您可以在新的IDE中打開舊項目並構建它。實際上，你將遇到兩個問題 - 保存你的「這裏是我所有的源文件和我的編譯器選項」的元文件和你的實際代碼：.dsp和.dsw，現在當.sln和.vproj。第一個可能需要你漫遊6.0到7.0的升級過程到8.0，如果你不想或不能，你可能需要重建一個空的解決方案/項目並添加你的源文件到它並設置你的選擇。
然後，您需要處理自上次構建以來庫中的任何中斷更改。我認爲這可能是安全的CRT更改和for循環範圍。編譯器會爲你找到它們。你不會很喜歡改變這一切，但這是可以預料的。
順便說一下，我會一路走到VS2010，而不是到2005年。在很長的一段時間內購買自己，然後再做這件事。
「順便說一句，我會一路走到VS2010」+1 – anno 2010-06-04 13:29:38
-1：有兩個原因。理論上你應該能夠打開新的IDE並進行編譯，並不能反映從VC6移植到VC8的現實可能非常困難。此外，編譯器會告訴你需要修復的所有內容的建議簡直是錯誤的。就像你不能使用編譯器告訴你什麼是符合標準一樣，你不能依賴編譯器來在移植時發現所有的錯誤。移植的代碼可能會編譯，但仍不能按預期運行。您必須瞭解所有重大更改，而不僅僅是編譯和編輯。 – 2010-06-04 14:18:05
是的，理解。但是，沒有找到。所以你應該瞭解循環範圍的變化。但是，您不必再看3000個循環來查看哪些變量事後重新聲明變量......編譯器會爲您找到這些變量。 – 2010-06-04 15:08:34
我在this post上強調了從VC6到VC9的移植。去年，我從VC6移植到VC9的一款百萬線程的單片應用程序，事實證明這非常困難。 VC6由於即使出臺也不是非常符合標準而臭名昭着，隨着標準在未來幾年的發展，VC6的合規性變得更糟。微軟利用這個機會在很大程度上解決了VC7中的這個問題，但是這樣做破壞了很多在VC6中編譯的代碼。
在某些情況下，代碼被破壞是因爲代碼本身很差，VC7是一個更好的編譯器，不允許VC6做許多自由度。但在許多情況下，由於合規性的提高，「良好代碼」（從VC6的角度來看）變成了非法代碼。一個非常簡單的例子：
for(int i = 0, cont = 1; cont; ++i)
{
// count something up
}
cout << "The number is now " << i << endl;
該代碼是完全沒有儘可能VC6而言，但是根據i在for塊的端部超出範圍的標準。有許多其他很多這樣的例子，從VC6變成VC7（從VC7變成VC8等）。在繼續之前，您應仔細閱讀這些變化：
我們有許多令人信服的理由移動到VC9不僅僅是更好地遵守。一個是編譯64位應用程序的能力，所以我們最終決定移植整個應用程序。但你可能有其他選擇。
如果編譯器僅在代碼的一部分中爲您創建障礙，則可考慮移植該部分，並創建一個在VC9中編譯的圖層，以彌補VB 8.0與VC6應用程序之間的差距。這可能不過是一個編組代理，它只不過是在主應用程序和第三方組件之間移動數據。
在VS2005中打開項目。編譯。看看什麼擊中粉絲。 – 2010-06-04 13:11:17