まだ開発中の共有アセンブリを参照する方法（.NET）

Question

私は、製品アプリケーションの構築に使用される共通のフレームワークアセンブリのセットを開発および保守する責任があります。これらのアセンブリは比較的新しく、新しい機能が実装されるなど、流動的な状態にあります。その結果、それらが何度も再構築および再配布されることは珍しくありません。アセンブリが安定化されるにつれて、これは減少すると予想されますが、それは今日の状態です。

今、アセンブリは、開発プロジェクトが同じアセンブリを参照できる共通フォルダーに配置されます。更新の適用は、ファイルを置き換えるだけで簡単で、開発プロジェクトは、次回の読み込みとビルド時に変更を自動的に取得します。

私が抱えている問題は、いくつかの「レイヤー」があることです。フレームワーク上に構築されたアセンブリ-たとえば、すべてのアプリケーションで共有されるコアライブラリと、コアを参照し、すべてのサーバーアプリケーションで共有されるサーバーライブラリがあります。また、フレームワークアセンブリが更新されるたびにすべての依存関係を再構築する必要があり、これは非常に大きなタスクになります。新しいバージョンがリリースされるたびにすべての開発者がシステムを更新する必要があるため、GACを使用できるとは思わない。

出版社のポリシーを調査しましたが、いくつかの理由でこれが私の問題を解決するのではないかと疑っています。

• 1つには、フレームワークアセンブリを再構築するたびにファイルを再作成したくない-このプロセスを自動化する方法はありますか？

• アセンブリがGACに入る必要があるかどうかは明確ではありません。先ほど言ったように、新しいバージョンのアセンブリをリリースするたびに、開発者に再インストール、更新などを強制するのは望ましくありません。

• ネットワークのセットアップと構成を制御できないので、「信頼」全体を避ける必要があります。ネットワーク共有にファイルを配置することによる問題。さらに、開発者の多くは時々接続された方法で作業するため、切断されたときにファイルを利用できるようにしたいと考えています。

目標は、これらのアセンブリの更新を、それらを使用しているアプリケーション開発者に対して透過的にすることです。アプリケーションをインストールするときに、これらのアセンブリをターゲットマシンのGACにインストールすることは間違いありませんが、開発目的のためにインストールするのは望ましくありません。また、プロジェクトは異なるチームによって開発されているため、各アプリケーションのソリューションにプロジェクトを含めることは合理的ではありません。

これらの要件に私が一人でいるとは想像できません。誰かが自分の経験と知恵を共有して解決策に導くことを期待しています。ありがとう！

Answer 1

NuGetはこの問題を解決しました。ネットワーク上のプライベートリポジトリからNuGetパッケージとして共有アセンブリ、フレームワークなどを配布することにより、更新を簡単に投稿し、必要に応じてクライアントコードに適用できます。

Answer 2

必ずしもGACにアセンブリをインストールする必要はありません-セットアップでこれを必要とするものはありません。

ここでの主な問題は、アセンブリがすべての依存関係を強制的に再構築し、これらすべてが共有場所に配置されるようにすることです。

ここで最も簡単なオプションは、おそらく、共有アセンブリの1つが更新されるたびにすべてを再構築するビルドサーバーを持つことです。これには、他の「スクリプト」を実行する可能性があるという利点もあります。ビルドがチェックインされるたびに、コードメトリックス、静的コード分析などを行うなど、ビルド時。

その後、ビルドサーバーにすべてを共有場所までコピーさせることができます。プロジェクトが共有の場所から参照し、特定のバージョンに制限しないことを明示的に言っている場合、すべてが正常に機能するはずです。