.NET 2.0 RTMのみが存在する場合、ランタイムは.NET 2.0 SP1アセンブリへの呼び出しをどのように解決するのですか？

Question

.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にPublisherポリシーまたはリダイレクトが存在しないため、アセンブリのバインディング処理が失敗するはずです。しかし、バインディングは正常に動作します。どのようにすることができますか？

上記の問題のもう1つの質問。

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

更新1： System.Xml.dllのバージョンは2.0.0.0で、2.0.50727.xではありません。それはランタイムがそれをうまく解決する理由を説明します。しかし、2番目の質問は引き続き適用されます。アプリケーションからSP1のSystem.Xml.dllを出荷し、アプリケーションに強制的に使用させることはできますか？

Answer 1

受け入れ可能な回答がない場合は、自分で投稿します。誰かを助けることを願っています。

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

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

私はまだMSがサービスパックのアセンブリを増やしていない理由について興味がありますAssemblyVersion？アセンブリバインディングをRTMからSPにリダイレクトするために、SP'sアセンブリを対応するパブリッシャポリシーと一緒に出荷できます。また、クライアントがRTMバージョンのアセンブリを使用したい場合は、特定のアセンブリのパブリッシャポリシーを無視できます。実際には、私はMSがそのように行くことを拒否したと思う。なぜなら、クライアントが一部のアセンブリでパブリッシャーポリシーを無視し始め、他のメンバーを無視しないと、それは完全に混乱するからだ。 BCL'sアセンブリよりも互いに依存することはできませんでしたが、BCL全体が不一致になります。

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

短い答えは「いいえ、できません」です。しかし、2つの可能な解決方法がありますが、彼らは非常に不自由であり、厳しい状況下でのみ使用できる可能性があり、一般に適用できません。

最初の解決方法は、CLRアセンブリを崩壊してから、公開鍵を使用して再構築するか、まったく強力な署名を省略することです。これで、GACのSP'sアセンブリではなく、RTMアセンブリを参照できるようになります。

2番目の解決方法は、gacutilツールを使用して、GACのRTM'sアセンブリをSPのアセンブリに置き換えることです。 /f（強制）オプションを使用する必要があります。

これらの2つのソリューションは、どちらも非常に不慣れです。それらを使用しないでください。一般に、アセンブリ間の依存関係のために使用することはできません。それは.NET 2.0 RTMに仕事ができるよう

結論は、私たちの製品では、私たちは私たちの製品を格下げ。しかし、我々はまだ.NET 3.x（linq-to-objects,Action,Func）からいくつかの機能を使用しています。私たちは、3.xアセンブリのいくつかを私たちの製品で出荷します。 System.Core.dll。ほとんどの場合、このアプローチでは問題はありません。しかし、解決できない問題があるため、Linq-to-Xmlを使用して拒否しなければなりませんでした。

Answer 2

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

SP1を使用してコンパイルしたときにRTMバージョンでプログラムが正しく動作することは期待できません。それは正しく動作するかもしれませんが、不思議な方法で失敗することもあります。