私は、製品アプリケーションの構築に使用される一連の共通フレームワーク アセンブリの開発と保守を担当しています。これらのアセンブリは比較的新しく、新しい機能が実装されるなど、流動的な状態にあります。その結果、再構築や再配布が頻繁に行われることは珍しくありません。アセンブリが安定化するにつれて、これは減少すると予想されますが、現在はそうです。
現在、アセンブリは、開発プロジェクトが同じアセンブリを参照できる共通フォルダーに配置されています。更新の適用は、ファイルを置き換えるのと同じくらい簡単で、開発プロジェクトは、次回のロードおよびビルド時に変更を自動的に取得します。
私が抱えている問題は、フレームワーク上に構築されたアセンブリのいくつかの「レイヤー」がある可能性があることです。たとえば、すべてのアプリケーションで共有されるコア ライブラリと、コアを参照し、すべてのサーバー アプリケーションで共有されるサーバー ライブラリがあります。フレームワーク アセンブリが更新されるたびにすべての依存関係も再構築する必要があるため、これは非常に大きなタスクになります。新しいバージョンがリリースされるたびにすべての開発者がシステムを更新する必要があるため、GAC を使用できるとは思えません。
パブリッシャー ポリシーを調査しましたが、いくつかの理由から、これで問題が解決するかどうか疑問があります。
1 つには、フレームワーク アセンブリを再構築するたびにファイルを再作成したくありません。このプロセスを自動化する方法はありますか?
アセンブリを GAC に入れる必要があるかどうかはわかりません。前述したように、アセンブリの新しいバージョンをリリースするたびに、開発者に再インストールや更新などを強制したくありません。
ネットワークのセットアップと構成を制御できないため、ファイルをネットワーク共有に配置して、「信頼」の問題全体を回避する必要があります。さらに、当社の開発者の多くは時々接続された方法で作業しており、切断されたときにファイルを利用できるようにしたいと考えています。
目標は、これらのアセンブリを使用しているアプリケーション開発者に対して、これらのアセンブリの更新を透過的にすることです。アプリケーションのインストール時にこれらのアセンブリをターゲット マシンの GAC にインストールすることは間違いありませんが、開発目的ではそうしたくありません。プロジェクトは異なるチームによって開発されているため、各アプリケーションのソリューションにプロジェクトを含めることも合理的ではありません。
これらの要件を抱えているのは私だけだとは想像できません。誰かが経験と知恵を共有して、私を解決策に導いてくれることを願っています。ありがとう！