3

.NET 2.0 SP1 がインストールされたマシン上で、.NET 2.0 に対してアプリケーションを構築しました。アプリケーションは、.NET SP1 に含まれるいくつかの標準 .NET アセンブリ (つまりSystem.Xml.dll) を参照します。

このアプリケーションを .net 2.0 RTM を搭載したコンピューターで実行すると、アプリケーションは正常に動作し、System.Xml.dllアセンブリも使用します。しかし、2.0 RTM には存在しないが 2.0 SP1 には存在するメソッドを使用しようとすると、アプリケーションはMethodNotFoundExceptionをスローします。

私の質問は次のとおりです。ランタイムは System.Xml.dll をどのように解決しますか?

アセンブリのバージョンはリビジョン番号が異なります (ただし、メジャー、マイナー、およびビルド パーツは同じです)。つまり、2.0 RTM アセンブリと 2.0 SP1 アセンブリは、アセンブリ バインディング プロセスに関して異なります。ランタイムは System.Xml.dll を見つけようとします2.0.50727.1378が、しか見つかりません2.0.50727.42。その後、アセンブリ バインド プロセスは失敗するはずです。これは、Machine.config にパブリッシャ ポリシーまたはリダイレクトが存在しないためです。しかし、バインドは正常に機能します。どうしてですか？

上記の問題に続くもう1つの質問。

すべてのクライアントに、コンピュータに .NET 2.0 SP1 をインストールするよう強制することはできません。.NET 2.0 SP1 から System.Xml.dll を出荷する場合、アプリケーションに付属の System.Xml.dll を使用させるにはどうすればよいでしょうか。

更新 1: System.Xml.dll のバージョンは 2.0.50727.x ではなく 2.0.0.0 のようです。これは、ランタイムが問題を正常に解決する理由を説明しています。ただし、2 番目の質問は依然として当てはまります。SP1 から System.Xml.dll をアプリケーションと共に出荷し、アプリケーションでそれを使用するように強制することはできますか?

4

2 に答える 2

1

受け入れ可能な回答がない場合は、私自身を投稿します。それが誰かに役立つことを願っています。

最初の質問は、ランタイムがサービス パックからアセンブリをどのように解決するかということでした。

私はもう少し調査し、いくつかの記事を読みました。AssemblyFileVersionの代わりにを誤って見てしまいましたAssemblyVersion。のアセンブリの場合.NET 2.0 SP AssemblyFileVersionは2.0.50727.1378、アセンブリ.NET 2.0 RTMの場合は2.0.50727.42です。はい、それらは異なりますが、そうではAssemblyFileVersionありませんAssemblyVersion。アッセンブリ・バインディング・プロセスAssemblyVersionのみを使用しています。しかし、どちらかのためAssemblyVersionです。したがって、アセンブリは、アセンブリ バインド プロセスに関しては同じです。2.0.0.0.NET 2.0 RTM.NET SPxRTMSPx

MS がインクリメント付きのサービス パックのアセンブリを出荷しなかった理由にまだ興味がありますAssemblyVersionか? SP'sアセンブリ バインディングを から にリダイレクトするために、対応する Publisher ポリシーを使用してアセンブリをRTM出荷できSPます。また、クライアントがアセンブリのバージョンを使用したい場合RTM、特定のアセンブリの発行者ポリシーを無視できます。実際、クライアントが一部のアセンブリの発行者ポリシーを無視し始め、他のアセンブリを無視しないと、完全に混乱するため、MS はその方法を拒否したと思います。アセンブリBCL'sが相互に依存できなくBCLなると、全体として一貫性がなくなります。

2 番目の質問は、.NET 2.0 SP1アセンブリを製品と共に出荷し、アセンブリ バインドをRTMアセンブリからアセンブリにリダイレクトする可能性についてでしたSP's。

短い答えは「いいえ、それは不可能です」です。しかし、2 つの可能な解決策がありますが、それらは非常に不十分であり、厳密な状況下でのみ使用でき、一般的にはまったく適用できません。

最初の解決策は、CLR アセンブリを disasm してから再度ビルドすることですが、公開キーを使用するか、厳密な署名をまったく省略できます。これで、GAC からRTMのアセンブリではなく、このアセンブリを参照できるようになります。SP's

RTM's2 番目の解決策は、ツールを使用して GAC のアセンブリを SP のアセンブリに置き換えることgacutilです。( /fforce) オプションを使用する必要があります。

これら 2 つのソリューションはどちらも非常に不十分です。それらを使用しないでください。一般に、アセンブリ間の依存関係のために使用できません。

結論

当社の製品では、 で動作するように製品をダウングレードしました.NET 2.0 RTM。.NET 3.xしかし、 ( linq-to-objects、Action、 )からでもまだいくつかの機能を使用していますFunc。3.x アセンブリの一部を製品とともに出荷するだけSystem.Core.dllです。ほとんどの場合、このアプローチで問題はありません。しかしLinq-to-Xml、解決できない問題がいくつかあったため、使用を断らなければなりませんでした。

于 2011-04-12T18:42:41.020 に答える
0

.NET のバージョン管理は、厳密な名前のアセンブリに対してのみ適用されます。

SP1 を使用してコンパイルされた場合、プログラムが RTM バージョンで正しく実行されるとは期待できません (期待すべきではありません)。正しく動作するかもしれませんが、不可解な方法で失敗することもあります。

于 2011-03-21T10:17:14.027 に答える