2012-11-28 19 views
12

Visual Studioでリリースモードでプロジェクトをビルドするときに問題が発生しました...アセンブリの形式が間違っているとエラーが表示されます。いくつかのx86アセンブリが、x64アセンブリの代わりに参照されていたことが分かります。 PresentationCore、System.Dataなどのアセンブリ。Visual Studio 2012で間違ったDLLへの参照が追加される

物事は私が試してみた:

  • デバッグモードでは、すべてのCPUは罰金構築します。

  • デバッグモードでは、x64は正常に動作します。

  • リリースモード、任意のCPUはx64のに失敗した

  • リリースモード、(これは私は私のプロジェクトをビルドしたいの組み合わせである)

を失敗した私がしようとすると、問題が来ますx86リファレンスを削除し、x64リファレンスに切り替えます。 Visual Studioでは、x64リファレンスの代わりに古いx86リファレンスを追加するだけです。たとえば:

私はを参照してC:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Data.dllを追加C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll

であるSystem.Dataの参照を削除し、私はSystem.Data参照が、パスが古いdllファイルにはまだ明らかにすることを上のクリックしたときと同じエラーが発生します。これは、他のいくつかのDLLでも起こっています。

この問題の解決方法を知っている人はいますか?

答えて

18

PresentationCore、System.Dataなどのアセンブリ。

エラーメッセージが表示されずに質問に答えるのは嫌です。しかし、この二次的な証拠が問題に答えるには十分です。まず、これはではなく、というエラーです。警告です。

警告CS1607: - 参照アセンブリ「のSystem.Data.dll」目標異なるプロセッサ

あなたはまたのMscorlib.dllのための1つを参照してくださいよアセンブリ世代それはこのようになります。そしてWPFプロジェクトのPresentationCore.dll。ここでは、これらのアセンブリが特別なであり、これらは混在モードのアセンブリです。つまり、ネイティブコードとマネージコードの両方が含まれています。ネイティブコードはトラブルメーカーですが、このようなアセンブリは、正しいプロセッサのフレーバーをターゲットとするプロジェクトでのみ使用できます。それを混ぜると、実行時にBadImageFormatExceptionが発生します。

これは.NETアセンブリでは実際の問題ではありませんが、実際にはマシンにはという2つののDLLがGACに格納されています。プログラムが32ビットモードで実行され、別のプログラムが64ビットモードで使用される場合に使用されます。 CLRは自動的に正しいものを選択します。

参照アセンブリは、c:\ windows \ microsoft.netに格納されているものと、メタデータを読み取るためにコンパイラに渡すバージョンが1つだけあります。それは常にx86版ですが、他のものはありませんので、それを探して気にしないでください。ここでも、これは問題ではなく、参照アセンブリのメタデータのみがコンパイラによって使用され、そのコードは実行されません。また、メタデータはアセンブリのビット数に依存しません。

ただし、このすべてのとなる場合があります。独自の混合モードアセンブリを作成すると問題が発生します。 2つのバージョンを用意する必要性を簡単に見落とすことができます。だから、コンパイラは、あなたがプロジェクトのAnyCPUまたはx64ビルドを要求したことを知っていることに気づいています。しかし、参照アセンブリがx86を対象とする場合にのみ動作することを検出します。だから、ちょっと声を掛けます。あなたが間違っているという証拠があり、プログラムを実行するときにBadImageFormatExceptionが発生する可能性があることを丁寧に覚えておいてください。他の方法では、フレームワーク参照アセンブリを自分の参照アセンブリとは異なるものとして扱うことはありません。

これは機能であり、バグではありません。そうしないとプログラムがビルドできなくなります。 を認識しているため、実行時に.NETにGACで正しいアセンブリが使用可能であるため、警告を無視しても問題ありません。注目すべきは、.NET 4.0にはこの問題がなく、ILONLYメタデータフラグがオフになっていない非常に異なる参照アセンブリが使用されていることです。

6

奇妙な動作。プロジェクトプロパティの[ビルド]で[シリアル化アセンブリを生成]をオフにすると、プロジェクトはリリースモードで正常に構築されます。 this linkを見ると、この設定はXMLシリアライゼーションと関連していることがわかります。これはソリューション全体でも使用されていません。

非常に奇妙です。まだこの質問と行動の説明を探しています。

1

コンパイルする.NETのバージョンは?プロジェクトを.NET Frameworkのそれ以降のバージョンに変更できる場合は、役立つ可能性があります。

+0

.NET 3.5用にコンパイルしています。残念なことに、フレームワークの変更は問題になりません。なぜフレームワークの変更が効果を生むと思いますか?私の質問のDLLは、これらの2つのバージョンから完全に独立しています、それはちょうど異なるプロセッサプラットフォームです。 – tnw

+0

提案[ここ](http://connect.microsoft.com/VisualStudio/feedback/details/525599/compiling-an-net-application-for-x64-platform-on)のように、プロジェクトファイル内の参照を手動で変更してみてください-64ビット-os-not-generate-cs1607-警告)(2010年7月12日3:23 PMにMicrosoftによって投稿されたもの) – Jargon

+0

ええ、csprojファイルで直接変更することは確かに唯一の方法です転送する参照を取得する。しかし、まだ、デバッグとリリースがビルドされない理由については説明していません。 – tnw

2

ビルドの設定がどのようになっているか確認してください。このエラーは、ソリューション上の特定のプロジェクトが別のビルド構成でビルドされるように構成されているために発生することがあります。 「>コンフィギュレーション管理をコンパイル...」する

  • 「アクティブソリューション構成」で、あなたに問題を与えている構成です「Release」を選択し

    1. 移動します。これを行うには

    2. "アクティブソリューションのプラットフォーム"で "任意のCPU"をオンにします。 "x64"が定義されている場合は、それを選択することもできます。
    3. ビルドプロジェクトのリストを見てください。ソリューションに必要なすべてのプロジェクトには、「構成」、「プラットフォーム」に正しい値が設定され、「コンパイル」チェックが必要です。

    私のケースでは、コンパイルに時間がかかるため、少なくともデバッグモードではほとんどの時間をチェックしないという砂時計プロジェクトがあります。時には、1つのプロジェクトに "リリース"構成の構成がないため、ビルドプロセスがその結果を取得しようとすると、DLLが存在せず例外がスローされます。他の状況では、プロジェクトがx86(またはx64)用にコンパイルされなければならず、残りのプロジェクトは参照されないため、他の参照プロジェクトを参照されたDLLの適切なバージョンにリンクしようとするとエラーがスローされます。

  • 1

    私のVS2010 Webプロジェクトもこれらの警告を生成していましたが、IISはBadImageExceptionをスローしていました。ビルド/設定/プラットフォームの設定はOKですが、出力ウィンドウには、dllが任意のCPU構成のx64フォルダに組み込まれていることが表示されていました。 binの下のすべてのフォルダを削除して再構築しました。警告が消え、BadImageExceptionはなくなりました。

    +0

    あなたのソリューションを共有していただきありがとうございます。 – tnw