19

このビルド エラーの原因を特定する方法を知りたいです。

Warning 4   The primary reference "MyNamespace.MyProject" could not be resolved because 
   it has an indirect dependency on the .NET Framework assembly "System.Xml, Version=4.0.0.0,
   Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than
   the version "2.0.0.0" in the current target framework.   MyNamespace.MyOtherProject

私はこのエラーの意味を理解しています (そして、この同じプロジェクトで他の 5 人がそれを気に入っています) が、私の場合は解決方法がわかりません。この場合の「プライマリ リファレンス」(MyNamespace.MyProject) には、.NET 4.0.x への直接的な依存関係はありません。

プライマリ リファレンスは、私の他の 1 つのプロジェクト (MyNamespace.MyCoreProject) のみに依存し、ビルドのソース プロジェクト (MyNamespace.MyOtherProject) も直接依存しています。そして、ビルドはそのプロジェクトが .NET 4.0.x への間接参照を持っていることについて不平を言っていないので、それを除外できると思います。

プライマリ リファレンスは、3 つのサードパーティ DLL に直接依存しており、そのすべてが .NET 2.0 をターゲットにしています。

ビルドされたライブラリを調べるために dotPeek を使用しましたが、.NET 4.0 を使用したものへの参照が表示されません。

作業中の他の唯一の潜在的なスパナは、'MyNamespace.MyCoreProject' (プライマリ参照プロジェクトによって参照される) によって直接参照される PostSharp の使用です。 PostSharp.dll (http://www.sharpcrafters.com/forum/Topic4444-4-1.aspx#bm4462) を参照していますが、これもビルド チェーンから削除しましたが、このエラーが引き続き表示されるため、ルールも適用できると想定しています。それを。

誰かがなぜこれが起こっているのか教えてくれたら、素晴らしいです! そうでない場合は、名前のない「間接参照」が何であるかを理解する方法についての指示があれば、同じように役立ちます!

ちなみに、情報を得るために次のツールをすべて試しましたが、私がまだ知らなかった多くのことを教えてくれませんでした (問題の DLL の直接的な依存関係です)。- .NET Reflector - dotPeek - IldAsm - Depends (Dependency Walker)

4

8 に答える 8

7

MsBuild が使用する参照を決定する方法を決定する問題を実際に解決するための良い方法を実際に解決したわけではありませんが (なぜ、これらの間接参照をどのように思い付くかを教えてくれません。知っている...） 私は自分の問題を解決しました。

最後に、.NET 4.0 ライブラリへの想定される間接参照のソースが、参照されたサード パーティの DLL。

ただし、この問題の背後には MsBuild のバグがあると思います。

  1. サード パーティの DLL が、'Browse' によってマシン上の特定の DLL ファイルに参照されました。
  2. ビルドで「特定のバージョン」を true に設定しても、これは修正されませんでした
  3. MsBuild は、この DLL の別のバージョンを求めて GAC に移動しているように見え、誤った参照エラーを引き起こしています。

さて、別の好奇心は、関連するライブラリにしばらく触れたり変更したりしていないことです。これは、他の無関係な理由で発生し始めたばかりです-それが何であるかはわかりません

最終的に、この問題を解決するために私が見つけた唯一の方法は、関連するライブラリごとにgacutil /uを実行して、以前にインストール/使用されたバージョンの 4.0 ライブラリを削除することでした。(パッケージには約 40 が含まれていたので、これも苦痛でした! パッケージのアンインストーラーが GAC のライブラリを削除しなかったためです)

これにより、msbuild は、「このファイルを使用する」および「この特定のバージョンを使用する」という意味について独自の考えを思いつくのではなく、私が指示した参照を使用し始めたようです。

解決しましたが、これを行うためのよりクリーンな方法が大好きでした!

于 2012-06-07T00:26:03.293 に答える
2

私はこの問題を抱えており、CheckAsm を使用して、何らかの奇妙な理由で自分のアセンブリの 1 つがサードパーティ ライブラリの .NET 4.0 バージョンを参照しているのに対し、アプリ自体は .NET 2.0 であると判断しました。そのアセンブリのすべてのインスタンスをハード ドライブから削除し (多くのコピーが横たわっていました)、ソリューションを再構築しましたが、すべて問題ありませんでした。

于 2013-12-06T01:17:39.093 に答える
2

すべての疑わしいアセンブリに対してMSIL 逆アセンブラーツールを使用してみてください。

  1. Dll を開き、Ctr + M をクリックして画面の最後に移動します。次のような .NET 4 アセンブリへの参照が表示される場合があります。

AssemblyRef #1 (23000001)

Token: 0x23000001
Public Key or Token: b7 7a 5c 56 19 34 e0 89 
Name: mscorlib
Version: 4.0.0.0
Major Version: 0x00000004
Minor Version: 0x00000000
Build Number: 0x00000000
Revision Number: 0x00000000
Locale: <null>
HashValue Blob:
Flags: [none] (00000000)

  1. 検索条件として inf ref # を使用して、その .NET アセンブリから読み込まれた型を検索します。これは、画面で見つけることができるタイプのサンプルです

    TypeRef #18 (01000012)

    トークン: 0x01000012
    ResolutionScope: 0x23000001
    TypeRefName: System.Runtime.CompilerServices.CompilationRelaxationsAttribute

  2. そのタイプが使用される理由を調べてください。

更新: Tools\Options\Projects and Solutions\Build And Run ページで MSBuild Project Build Output Verbosity を "Detailed" に設定してから、ソリューションをリビルドしようとしましたか? ResolveAssemblyReference ターゲットに何かが表示される場合があります

于 2012-06-06T03:55:40.227 に答える