我們有一個.Net framework 4軟件解決方案，其中包含許多.dll文件。如何減少通過網絡運行的.net dll數
這些文件託管在網絡服務器上，並從客戶端運行在公用遠程文件夾上。
我們希望減少此服務器文件夾中的.dll文件數量。確實出現
一些問題：
大部分這些.dll實際上都是通過COM可見接口從32位非託管代碼中調用的。
單個較大的DLL不應比啓動或執行多個較小的DLL慢。它的啓動速度可能會更快，因爲操作系統不需要做太多的初始化工作。不過，我懷疑你會注意到其中的差異。擁有較少的DLL會稍微減少程序的內存佔用量。再次，不是很多。
我不會推薦在通過網絡提供的DLL上運行NGen。 NGen旨在爲其運行的處理器進行編譯和優化。如果您的客戶端機器具有不同的架構，NGen映像可能不是最佳的，或者它可能無法正常工作。
附加意見後：
爲改善啓動時間的詳細信息，請參閱Improving Application Startup Time。也Writing High-Performance Managed Applications : A Primer。
另外請注意，加載程序不會JIT整個程序集。它根據需要進行調試。如果程序沒有使用程序集中的類，那麼該類的代碼將永遠不會被打亂。此外，一種方法在第一次使用之前不會被打亂。所以如果你永遠不會調用方法Foo.Bar()，那麼它將永遠不會被打亂。
NGen當然應該在客戶端運行。根據客戶端HW，恕我直言，它將製作一個私人優化版本。 –
但是，如果您在客戶端上運行NGen，則必須將生成的DLL存儲在客戶端或網絡共享上的每個客戶端目錄中。這似乎與您提出的減少文件數量的解決方案不一致。它使得應用程序的分發變得更加複雜，因爲您必須確保客戶端在應用程序更改時運行NGen。 –
你確定它不會更慢/更快嗎？我在哪裏可以找到有關dll加載，JIT和客戶端庫準備的信息？例如，如果不是所有的小型庫都沒有使用（在大型軟件解決方案中它確實發生過），初始化一個包含一些不需要的接口的大型庫不會更慢嗎？ –
這從壞的前提開始：將COM服務器存儲在網絡共享上是一個非常糟糕的主意。他們需要註冊，註冊表將包含在特定時間映射的驅動器號。當驅動器映射稍後不一致時，很難診斷故障。由於無論如何都需要在每臺機器上完成，所以您可能需要複製DLL並將其解決。 –
@Hans關於COM註冊，它由啓動時由未受管理的應用程序自動從服務器檢索到的.reg文件中完成。它運行良好，使用網絡UNC完整路徑和註冊表中的HKEY_CURRENT_USER類路徑註冊當前用戶。如果需要，.reg的私人副本停留在客戶端上以僅註冊一次。所以我們不必在客戶端上部署或運行任何東西，並且仍然確保使用正確的COM接口。在這個實現中，我們沒有COM自動註冊的問題。 –