將VB.NET Winforms應用程序移植到C＃

Question

有沒有用於將VB.NET winforms應用程序移植到C＃的任何「良好」資源？我確信有一些軟件只是翻譯代碼，但我希望在同一時間重構代碼。保持它目前的形式是有問題的，因爲它使用了VB.NET允許的一些「不好的設計」實踐，並且會使未來的維護更加複雜。這裏有沒有人經歷過這個過程，你是怎麼做到的？你使用翻譯/重構方法嗎？您是否只是使用最終產品來重新創建功能，而無需查看大部分代碼庫的當前代碼庫？你會（共同）推薦什麼？

更新：

當我告訴Grauenwolf，保持在其當前的語言提出了以下問題：

• 不能夠很容易地添加功能。 VB.NET不是一門我非常喜歡的語言。我非常欣賞學習語言的諷刺意味，但是將來的維護需要考慮到不懂VB.NET的人。其他應用程序已移植到C＃（很久以前，事實上）;我們想要添加的所有功能都取決於應用程序的分離（現在它非常緊密地耦合在一起）。我的選擇是用我不太熟悉的語言重構它，或者用我理解的語言來重構它。

爲了任何人誰投贊成票的問題了，我真的不知道爲什麼你做;關心的不是我是否應該把它留在VB.NET中;關注的是現在不移植它的未來成本是多少。如果我在修復它時花費很大的代價，爲什麼不去額外的步驟，併爲未來的程序員維護？

作者注：我沒有看在年齡這個問題，有一個最近的迴應，讓我感動我的「答案」到這個問題，並刪除了「答案」（因爲它是不是一個真正的回答）。

Answer 1

根據我的經驗與一些大型應用程序混合使用VB和C＃項目，我建議將它留在VB.NET中。如果設計出現問題，請修復它們，但將整個事情轉換爲C＃聽起來像是一種凌亂的，不必要的分心。

這兩種語言之間的非文體差異非常小，因此很難看到強制轉換的功能需求。 （在Visual Studio 2003中有一箇舊的bug，排除了某些特定的項目引用鏈，它們以特定的方式混合了C＃和VB項目，但這是我遇到的唯一一個實際障礙。）

Individual開發人員肯定傾向於傾向於某種風格偏好，但完全轉換是需要做大量工作才能體現不同口味的語法糖的。

Answer 2

如果您使用類似Reflector或Anakrino的東西，它的輸出基於IL而不是原始源。無論它是否產生更好的代碼，都可以進行辯論......但無論如何，你可以嘗試一下。 :)

Answer 3

我已經使用C-Sharpener在我們的一些應用程序上進行了轉換，但它並不完美。它轉換了大約95％的代碼，並且在我手動修復剩下的5％時我最終重構了代碼。

Answer 4

在我的工作中，我們使用了developerfusion的翻譯器，但沒有自動執行（只需翻譯一段代碼或類，然後手動將結果粘貼到C＃項目中）。

反射器是一個很好的工具，但在閱讀lambda函數時可以發現一些問題。

對於重構，我們嘗試過的最好的工具是Refactor Pro。

Answer 5

保持它的當前形式是有問題的，因爲它使用了VB.NET允許的一些'壞設計'實踐，並且會使未來的維護更加複雜。

你認爲C＃不允許壞設計？

問題不在於VB，問題在於編寫它的人和拒絕修復它的人。所以退後一步，深呼吸，然後開始修復代碼。誰知道，你可能會發現這些「糟糕的設計實踐」中的一些實際上很有意義。

Answer 6

我在VB.NET上有2年左右的經驗，但現在我只在日常開發中使用C＃。在我嘗試使用VB.Net to C#將我的VB.NET代碼轉換爲C＃之前，我從它和書中學到了東西。

Answer 7

哇！我是抓住這些東西的最後一個人。我在WinForms中有一個非常大的VB.NET代碼，並且已經被分配到端口號爲C＃和WinForms。 我有VB 0知識，但必須完成任務。我用T elerik Online Code Converter將所有的VB業務邏輯轉換成C＃。 該轉換器是一個愚蠢的，我提出了大約5000 erros主要混淆了[]與（），ref參數和線程的問題以及什麼不是。 編譯器（VS 2013）甚至無法找出單個構建中的所有錯誤。我必須花費2個月的時間來修復這些錯誤並一次又一次地構建項目。 我將WinForms UI複製到C＃Winforms UI - 這不是什麼大問題，現在我已經同時調試了兩個代碼以查看輸出。

我想告訴它，現在4個月了，我仍然在完成這個項目。 我的經驗很差勁，不想推薦任何人。