這是GAC的有效用途嗎？

Question

我們有一個很大的winform應用程序，我們在用戶磁盤上安裝。 我們希望第三方能夠編寫使用我們某些應用程序功能的應用程序。所以我們編寫了API.dll，它通過解析註冊表中的安裝目錄來與其他一些程序集進行交互。我們將API.dll作爲SDK發送給第三方。有幾個選項，爲第三方應用程序的實際部署如何將看起來像：

1. 他們「複製本地」 API.dll和船舶它。缺點：我們無法在API.dll中進行更改（當然不會中斷），因爲客戶應用程序已將其複製。如果我們改變它所交互的其他程序集（我們可能會），我們可能需要改變它。

2. 第三方不附帶API.dll，而是我們把API.dll放在GAC中。缺點：GAC的麻煩，簽署。

3. 與＃1相同，但API.dll只有抽象+工廠從我們的/ bin加載它們。缺點：可能並不總是微不足道，有些工作。

我不喜歡GAC，並儘量避免它，但團隊中的一些人在這裏做點事。你怎麼看？

Answer 1

一般而言，作爲潛在客戶，我會不惜一切代價避免GAC。

關於第1點，我認爲您的客戶應用程序（和開發團隊）更願意在自己的休閒和測試周期中部署您的更新，而不是依賴於您的更新。那樣的話，他們在準備好之後會更新你的更新 - 如果他們已經繞過了你剛纔修復的「bug」呢？

關於第2點，除非按照您自己的文檔中顯示的約定，否則您將很難讓所有人實際使用此機制。當然，我仍然總是使用第三方程序集的本地複製部署。

關於第3點，你可以這樣做......但它可能會惹惱你的顧客。如果您要做出如此大的努力來更新第三方供應商軟件，或許您應該懷疑您是否已經儘快發佈了您的庫。

從你的角度來看，我寧願保留做出突破性改變的權利（當然也包括它）。如果你的升級模式不允許你正確地重構和廢棄舊代碼，那麼你將有一個艱難的時間讓你的產品變得更好。

我的兩分錢。