DLL適合我嗎？

Question

我有相當多的代碼，我發現自己一遍又一遍地在各種應用程序中使用。我最近決定花時間把它們組織在一個地方，以便我可以從我的任何解決方案中引用它們。我從一個類庫項目開始，並添加了一些不同的函數和一些我使用的派生控件。一些功能被派生的控件使用，以及直接從應用程序中調用。我建立了這個項目並開始在我的項目中使用這個DLL。

我有一個關於這個習俗DLL（我使用Visual C＃2010速成）幾個問題：

1. 我首先注意到的是，它似乎並沒有工作，很喜歡股票微軟庫。例如，我可以有「使用System.Windows.Controls;」在程序中，但我只能使用using指令引用自定義庫的名稱空間。如果有意義的話，以類似的方式組織我的課程會很好。是否有可能像微軟那樣嵌套類？

編輯：例如...如果我在我的應用程序代碼的頂部鍵入「using System」，我會得到一堆可供選擇的子命名空間。我繼續輸入「Windows」，並獲得更多子類別。如果我添加對MyCustom.dll的引用並開始鍵入「使用MyCustom」，我沒有看到我的任何類或子類。我只是問如何在我的類庫中組織事物，以便它們像庫存一樣。

1. 使用我所有的可重用代碼創建一個大的DLL文件是一個好主意嗎？我目前沒有大量代碼，但我想留下擴展空間。最佳做法是什麼？

2. 當我爲我的應用程序創建安裝程序時，如何處理我的DLL？我通常使用InnoSetup來製作我的安裝程序。

3. 這是我主要關心的......說我使用Application1中的自定義DLL中的函數，並且有人安裝它。我後來添加了一些功能或對我正在構建的Application2的該功能進行了更改。如果新功能會破壞Application1或以不希望的方式更改某些內容，那麼當用戶安裝Application2時會發生什麼？我的自定義DLL是在應用程序之間共享還是每個應用程序都有自己的DLL版本？顯然，我會構建一個新版本的Application1以使其可以與新DLL一起工作，但不能保證用戶會更新它。

謝謝！

Answer 1

1）通過將類文件中的命名空間從：SomeNamespace更改爲：SomeNamespace.SubNamespace，可以讓代碼嵌入其自己的子命名空間中。順便說一句，如果在Visual Studio的解決方案資源管理器中爲項目添加「添加 - >新建 - >文件夾」，則VS在執行「添加 - >新建 - >類」時將自動使用「嵌套」命名空間，這將是您添加的文件夾的名稱。因此，如果您的原始名稱空間爲：MyDLLProject，並且將文件夾添加到名爲StartedStuff的項目中，那麼當您向該文件夾添加新的類文件時，您將看到名稱空間現在爲「MyDLLProject.HelpfulStuff」，因此，您將需要以這種方式在代碼中引用它，或者通過完全指定它，或者在需要使用其中包含的代碼的任何類文件的頂部包含「使用MyDLLProject.HelpfulStuff」。 2）將任何和所有可重用代碼封裝到DLL當然是一種好的做法，因爲它很容易在其他項目中使用，並且只需要更改一次，如果需要更改，不需要更改關於有多少項目使用它。但是，如果你確信你永遠不會在其他地方使用代碼，那麼這可能不值得花時間和精力。

3）InnoSetup應該自動包含您的項目引用的任何程序集（.NET DLL）。您可以看到什麼是DLL的引用，並添加項目樹中的「References」節點的引用，在VS的解決方案資源管理器中。這是你需要添加一個對你自己DLL的引用的地方，如果你選擇創建一個。

4）除非你真的在GAC（全局程序集緩存）中註冊使你的DLL成爲一個共享組件的麻煩，否則你不需要擔心這一點。您的應用程序將始終擁有自己使用的DLL副本，並且不會按照您想象的方式踩在其他腳趾上。

Answer 2

DLLs對於你正在嘗試做的事很好。

1）我可以有「使用System.Windows.Controls;」在程序中，但我可以 只使用使用 指令引用我的自定義庫的名稱空間。

其原因，這是是，MS暴露在它們的DLL多個接口。 要做到這一點，通常需要在您的DLL中註冊多個組件，實際上是使用您的代碼將您的類導出到客戶端。

2）用我所有可重用的代碼 製作一個大的DLL文件是一個好主意嗎？

DLL通常是部署佈局。所以，如果你的客戶只對你的代碼子集感興趣，那麼把代碼分解成更小的DLL，但除非需要，否則不需要它。 可以根據需要爲其他開發團隊提供特定的API組件，以便在需要時只發運較小的粒度組件，DLL越大，越多的客戶端越多地對它們產生影響。

3）當我爲我的 應用程序製作安裝程序時，如何處理我的DLL？我通常使用InnoSetup來製作我的安裝程序。

windows的現代安裝程序都包含分發DLL並在Windows註冊表中註冊DLL內部組件的功能。

4）這是我的主要關注......（跨 部署在同一個DLL）

在過去的多個版本，當人們部署自己的DLL到Windows系統文件夾，這是一個大問題。在部署良好的Windows應用程序中，情況已不再是這種情況。 Windows沙箱DLL自動安裝到應用程序本地，所以即使是一個認爲它安裝到system32或從那裏加載的應用程序真的沒有。你不必，只要你遵循DLL部署的規則和您的應用程序附帶您的dll擔心衝突，不要試圖迫使他們到系統目錄（該窗口可能不會反正讓

希望幫助

Answer 3

1. 我不明白你的問題，請重新字呢。
2. 有異，一般可重複使用的庫是特定於您的解決方案（如含普通enum類型的共享庫或數據庫模型） 。如果你只需要在不同的項目中重複使用代碼片段，可以將源文件複製到你的項目中，或者引用爲ource文件（VS會讓你這樣做），而不會複製它。如果你使用源代碼控制，請小心。
3. 沒有什麼可擔心的，DLL只是應用程序的另一個依賴項。 VS會（默認情況下）將DLL複製到你的應用程序項目的輸出目錄，所以你只需要配置你的安裝程序來包含bin文件夾中的所有文件（XML文檔除外）。
4. 除非你花費很大的麻煩才能使你的DLL在文件系統中共享（這在20世紀90年代當硬盤空間有限時很受歡迎，例如，請參閱「Microsoft Shared」文件夾）一個問題，因爲你的應用程序的每個分發將有自己的共享DLL副本（「共享」是在編譯時，而不是運行時）。如果應用程序嘗試使用不兼容的DLL文件進行啓動，而將其與針對其編譯的DLL文件進行比較，則.NET CLR將引發錯誤（並且您可以使用強命名程序集進一步強制執行此操作）。