8

バグのある DLL を GAC に登録しました (v4.2.0)。

したがって、そのバグを修正し、ファイル バージョンのみ (v4.2.1) を更新し (アセンブリ バージョンは v4.2.0 のまま)、新しい MSI パッケージをビルドしました。

問題は、DLL が GAC にインストールされていないことです。の DLL を右クリックしてこれC:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\v4.0_4.2.0.0__2269313d92725976を確認し、ファイルのバージョンを確認しましたがv4.2.0、C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL.

しかし！最初のバージョンをアンインストールしてから新しい DLL をインストールすると、GAC に正常にインストールされます。

私はこれに間違った方法でアプローチしていますか? 私たちのアプリケーションは特定のバージョンを使用するように設定されているため、アセンブリ バージョン v4.3.0 を作成して GAC にインストールするだけでは機能しません。

アップデート

発行者ポリシーに関する記事 ( http://support.microsoft.com/kb/891030 ) を見つけて、代わりに試しています。ポリシー アセンブリを生成しました。しかし、セットアップ プロジェクトに追加しようとすると、Visual Studio がクラッシュします =(

また、それをコンテンツ ファイルとしてプライマリ プロジェクトに追加しようとしました (そして、コンテンツ ファイルを GAC に追加しました)。しかし、その後、アセンブリが署名されていないと不平を言います。

だから私はまだ立ち往生しています。

4

2 に答える 2

5

バグ修正のために [AssemblyFileVersion] を更新することは、通常は適切なアプローチですが、GAC のアセンブリに対して更新すると不安定になります。アセンブリを使用し、意図せずにバグのある動作に依存して正しく機能する別のアプリを壊す危険があります。もちろん、パブリック メソッドの名前を変更するなどの意図しない間違いは、常にアプリを破壊する良い方法です。DLL 地獄への道は、悪いことが判明した多くの善意で舗装されています。

ただし、GAC は [AssemblyVersion] のみに注意を払い、ファイル バージョンは無視します。更新されたアセンブリを取得して既存のアセンブリを置き換えるには、最初に古いアセンブリを削除する必要があります。これは意図的なもので、偶発的な交換を防ぎます。

修復するアプリの .config ファイル内のA<bindingRedirect>は、発行元ポリシーよりもはるかに簡単に実行できます。

于 2012-12-18T10:33:53.647 に答える
0

これは、GAC が一意の識別子を与えるために使用する .NET アセンブリのパラメーターに関係していると思います。アセンブリのバージョンがこれらの一意性パラメーターの 1 つであるが、ファイルのバージョンがそうでない場合、それが症状を説明している可能性があります。具体的には、これは厳密な名前付きアセンブリに対する GAC の必要性に関係します。

このリンクは多くのことを言っています

http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx

于 2012-12-18T10:22:43.307 に答える