2

ここで、GAC に関するいくつかの投稿と、共有アセンブリを GAC にインストールしてアプリケーションを展開してはならない理由を読みました。これは、クライアント マシン上のアプリケーションの更新をより簡単にするはずなので、理にかなっています。

ただし、開発中とビルド サーバー上で GAC が役立つと思われる領域が 2 つあります。

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

次に、おそらくビルド サーバーに対して同じことを行います。ただし、これに関する唯一の問題は、バージョン 2.0 のアプリケーション ブロックを使用するアプリがあることです。後で、バージョン 3.1 を使用するようにこれをアップグレードします。ある時点で、顧客が発見したバグをテストするためにそのアプリケーションの以前のバージョンを再作成する必要があるかもしれませんが、ビルドを再作成すると、最初にビルドされたアプリケーション ブロックのバージョン 2.0 ではなく、バージョン 3.1 が選択されます。これは本当ですか、それとも GAC にある限り、古いプロジェクト ファイルは古いバージョンの dll を引き続き参照しますか?

この特定の点について、あなたの考え/意見は何ですか?

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

4

2 に答える 2

2

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

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

これにはいくつかの目的があります。

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

管理するプロジェクトが10以上ある場合、これはいくつかの違いを生み始めます。

于 2009-06-18T10:11:04.133 に答える
0

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

于 2009-06-18T10:02:01.827 に答える