開発とビルドのためのGACへの共有アセンブリのインストール

Question

ここでGACについていくつかの記事を読んで、共有アセンブリをGACにインストールしてアプリケーションを展開しないでください。これは、クライアントマシン上のアプリケーションの更新を容易にするはずだから、意味が分かります。

しかし、開発中とビルドサーバー上で役に立つGACがあることがわかりました。

たとえば、Microsoftアプリケーションブロックを使用する場合は、それらをGACにインストールしてそこに参照することができます。これは、実行するよりも簡単なので意味があります。パスを絶対参照することは、開発者のマシンごとに異なる可能性があります。また、すべての共有コンポーネントを共有ネットワークドライブにするよりも優れています。

おそらく、あなたのビルドサーバーで同じことをするでしょう。しかし、私がこれを見る唯一の問題は、アプリケーションブロックのバージョン2.0を使用するアプリケーションがあることです。後でこれをバージョン3.1を使用するようにアップグレードします。顧客が見つけたバグをテストするために、以前のバージョンのアプリケーションを再作成する必要があるかもしれませんが、ビルドを再作成すると、元々ビルドされていた2.0ではなくアプリケーションブロックのバージョン3.1が選択されます。これは当てはまりますか？GACに入っている限り、古いプロジェクトファイルはdllの古いバージョンを参照していますか？

この特定の点に関するあなたの考え/意見は何ですか？

GACにインストールされ、アプリケーションインストーラの一部として顧客のマシンに展開される「XCOPY」であるMSIとして、すべての開発者に（ダウンロードまたはビルドする）共有コンポーネントのすべてのバージョンを配布できるようにしたいと考えています。これを行うにはこれが最善の方法ですか？

Answer 1

古いアプリケーションは、新しいアプリケーションで古いアプリケーションを再構築しない限り、GACから古いバージョンのアセンブリを選択します。すべてのアセンブリは、この情報をそれ自身のマニフェストに保持します。 ILDasm toolを使用してアセンブリを開くと、参照されたすべてのアセンブリの情報を保持するアセンブリのマニフェストを詳細に検査できます。

Answer 2

この特定の点に関するあなたの考えや意見は何ですか？

私は常に.NETソフトウェアプロジェクトのリソース/ライブラリフォルダにプライマリバイナリを保存します。明らかに、このフォルダはバージョン管理されています。とにかく今日はストレージが安いので、大きな違いはありません。

これは、いくつかの目的があります：

• プロジェクトは、原子であり、彼らはGACにあるいくつかのライブラリの特定のバージョンを持つに依存しません。したがって、以前のリビジョンを単にチェックアウトするだけで再現するのは簡単です。そしてすべてがうまくいくでしょう。
• プロジェクトのチェックアウトを開始し、完全な統合ビルドを実行して作業を開始するには、クリーンな開発マシン（すべての.NETサービスパックとプライマリSDKがインストールされている必要があります）が必要です。

管理するプロジェクトが10以上異なる場合、これにはいくつかの違いがあります。