これはGACの有効な使用ですか？

Question

私たちはユーザーのディスクにインストールする大きなwinformアプリケーションを持っています。 当社は、第三者に、当社のアプリ機能の一部を使用するアプリケーションを作成させたいと考えています。そこで、レジストリからインストールディレクトリを解決して、他のアセンブリの一部とやりとりするAPI.dllを作成しました。 API.dllをSDKとしてサードパーティに送信します。それに

1. 彼ら「コピーローカル」API.dllと船：数などのサードパーティアプリの実際の展開は、次のようになりますどのようにするためのオプションがあります。短所：顧客のアプリケーションでコピーされているため、API.dllに変更を加えることはできません。それが相互作用する他のアセンブリを変更する場合は、それを変更する必要があります（これはおそらくあります）。

2. 第三者にはAPI.dllが付属していませんが、代わりにAPI.dllをGACに挿入します。短所：GACのハッスル、署名。

3. ＃1と同じですが、API.dllにはabstractions +/binから読み込むファクトリしかありません。短所：いつも些細なことではないかもしれない。

私は、GACが好きで、それを回避しようが、チームの何人かの人々がやるとここでのポイントを持っていません。どう思いますか？

Answer 1

一般的に潜在的な顧客として、私はGACを絶対に避けます。

ポイント1については、あなたの顧客のアプリ（および開発チーム）は、あなたの娯楽とテストのサイクルであなたのものに頼るのではなく、自分のアップデートを展開する可能性が高いと思います。そうすれば、彼らは準備が整ったときにあなたのアップデートを取ることができます。もしすでにあなたが修正したばかりの "バグ"を迂回してしまったら？

ポイント2については、あなた自身のドキュメントに示されている規約以外は、誰もが実際にこのメカニズムを使用するのに苦労するでしょう。とにかく、私はまだとにかく第三者のアセンブリのコピーローカル展開を常に使用しています。

ポイント3については、これを行うことができます...しかし、それはあなたの顧客を悩ませるかもしれません。サードパーティのベンダーソフトウェアを更新するような大きな努力をしているのであれば、あなたがすぐにあなたのライブラリをリリースしたかどうか疑問に思うはずです。

さらに、あなたの見解から、私はむしろ大きな変更を加える権利を留保したいと思います。あなたのアップグレードモデルで古いコードを適切にリファクタリングして廃止することができない場合は、あなたの製品をより良くするために苦労するでしょう。

私の2セントです。