如何在不破壞現有客戶端的情況下使用c＃重新實現舊的DCOM服務器？

回到當天，我使用ATL庫，使用VC++ 7.x（Visual Studio 2003和.Net 1.1）編寫了一個進程外（即EXE）COM服務器。服務器使用多線程公寓（MTA）模型，並由DCOM調用（VB6客戶端）激活。多個客戶端請求由單個進程滿足 - 由第一個請求激活（由COM基礎結構自動啓動）。如何在不破壞現有客戶端的情況下使用c＃重新實現舊的DCOM服務器？

這是相當複雜的一段代碼，我現在必須對它進行一些更改。不幸的是，我建立的機器早已不存在了，甚至在使用VS 2003的新機器上編譯項目時也遇到了問題。幾年前，我玩弄了將這個項目遷移到VS 2005，但有很多打破ATL庫的變化，我放棄了這一努力。

我沒有去解決當前構建這個舊的VS 2003 C++項目的問題，而是在.NET中重寫這個東西。這將使我的小商店更容易維護（我們不再使用C++）。 ATL宏和C++習慣早已從我的記憶中消失了，我想將它們留在那裏。 :-)

所以我正在探索在C＃/ VS2008中做這個重做的可行性。我知道你可以將.NET類暴露給COM客戶端。事實上，我過去一些簡單的東西就是這樣做的。但是，這更復雜。我不知道的一些事情：

的接口在由客戶所消耗的類型庫中的所有規定（即必須保持未改性）。我可以假設我可以構建一個基於現有類型庫實現這些接口的.NET服務器嗎？
服務器實現了許多從IDispatch繼承的接口，並標有「dual」和「oleautomation」。舉個例子：
```
[odl, uid(...), dual, oleautomation] 
interface IKDFTSearchManager : IDispatch { 

     HRESULT Method1(...); 
     HResult Method2(...); 
} 
```
我不相信任何一個客戶端使用IDispatch方法，但我會假設，通過互操作產生的虛函數表必須匹配。如何從.NET服務器公開這個？
什麼類型的項目應該包含組件？控制檯應用程序？
如果DCOM正在使用其中一個互操作工具正確註冊，則DCOM可能會激活EXE。是這樣嗎？基礎架構的行爲是否與C++/ATL服務器一樣 - 即導致單個EXE被激活，從而爲多個客戶端請求提供服務？
與（4）相關，該服務器是否將使用多線程模型？