我是構建新的ASP.NET 3.5 Web應用程序的開發團隊的一員。我們兩個是C＃編碼器，另一個是VB.NET編碼器。在Web應用程序中管理多種.NET語言
我知道，我們可以在每個項目的基礎上混合語言，並且可以建立在從寫在另一種語言在不同的項目中（我們已經做）的類繼承的一個語言班，但我可以看到我們陷入了一種情況，那就是我們最終會在各種項目DLL之間產生循環依賴關係。
除了僅僅擁有大量項目（更多關注更多圖書館的問題）之外，您是如何在自己的項目上管理這種情況的？
注 - 我相信這個問題是從唯一的相似匹配足夠的不同，我能找到（this one），我們不想爲了充分利用其特定的功能本身的優勢，使用不同語言的基礎上，但而是利用開發人員資源可用的東西（即一個開發人員恰好只是VB.NET）。
我說實話，我會讓vb.net的傢伙轉移到C＃。
遲早你會希望他在c＃項目的一部分解決方案上工作。它是您在創建新語法時創建的人爲障礙，相對比較簡單。
大多數開發者都希望有機會轉換到c＃。
我最近參與了一家大公司決定從vb.net轉到c＃，我們發現這增加了士氣，並且更容易找到合適的人選。
如果可能，我會避免這種情況。嘗試給VB編碼器提高他們的C＃。它不一定是直接的，讓他們現在編寫VB直到他們適應C＃，然後你可能想回去重構舊的VB到C＃中。他們已經習慣了.NET庫和工具，它主要是語法（但是，有一些語言差異）。
我建議這是爲了將來的維護的原因 - 你將不得不維護和調試兩種語言的代碼。如果你們都知道所有的語言，那麼這不是一個問題，但是你能確保永遠這樣嗎？
如果您的店鋪主要是C#，而且您確實希望您的項目得到開發，我會鼓勵其他開發人員學習C#，而不是因爲您的某個團隊成員缺乏相關知識而損害您的項目。這不是要放棄你的其他團隊成員，但是如果他/她對.NET有很好的掌握，那麼這個人沒有理由不能學習C＃。
我們在我的公司有兩種組合，但是，使用VB.Net的選擇總是取決於我們是否將現有的VB6應用程序移植到.Net，在這種情況下，使用VB.Net是有意義的，因爲更少的代碼必須被重寫（在大多數情況下）。但我們絕不會讓開發人員的技能決定是否使用C＃或VB.Net，我們會選擇最適合工作的工具，而且這應始終是決策點。