.net - Visual Studioのコンパイルエラー「プロセッサアーキテクチャ間の不一致」を修正するにはどうすればよいですか？

Question

Visual Studio 2010でのプロジェクト構成は初めてですが、調査を行った結果、この問題を完全に理解することはできません。C＃DLLを参照するC++DLLを使用したVisualStudioソリューションがあります。C＃DLLは、他のいくつかのDLLを参照します。一部はプロジェクト内にあり、一部は外部にあります。C ++ DLLをコンパイルしようとすると、次の警告が表示されます。

警告MSB3270：ビルド中のプロジェクト「MSIL」のプロセッサアーキテクチャと、参照「[internal C＃dll]」、「x86」のプロセッサアーキテクチャの間に不一致がありました。

アーキテクチャを調整するためにConfigurationManagerに移動するように指示されます。C＃DLLは、プラットフォームターゲットx86でセットアップされています。これをAnyCPUなどの他の何かに変更しようとすると、依存している外部DLLの1つにプラットフォームターゲットx86があるため、文句を言います。

Configuration Managerを見ると、C＃DLLのプラットフォームはx86として、C++プロジェクトのプラットフォームはWin32として表示されます。これは正しい設定のようです。確かに、C ++プロジェクトのプロジェクトでプラットフォームをx64に設定したくありません。これは、提示されている他の唯一のオプションです。

私はここで何が間違っているのですか？

score 572 · Accepted Answer

この警告は、新しいVisual Studio 11Betaおよび.NET4.5で導入されたようですが、以前は可能だったと思います。

まず、それは本当に単なる警告です。x86の依存関係を処理しているだけであれば、何も害はありません。プロジェクトが「任意のCPU」と互換性があると述べたが、x86またはx64のプロジェクトまたは.dllアセンブリに依存している場合、Microsoftは警告を表示しようとしています。x86に依存しているため、技術的にはプロジェクトは「任意のCPU」と互換性がありません。警告を消すには、実際にプロジェクトを「AnyCPU」から「x86」に変更する必要があります。これは非常に簡単です。手順は次のとおりです。

[ビルド]|[構成マネージャー]メニュー項目に移動します。
リストでプロジェクトを見つけます。プラットフォームの下に「AnyCPU」と表示されます。
ドロップダウンから[任意のCPU]オプションを選択し、[<New..>
そのダイアログで、[新しいプラットフォーム]ドロップダウンからx86を選択し、[設定のコピー元]ドロップダウンで[任意のCPU]が選択されていることを確認します。
OKを押す
デバッグ構成とリリース構成の両方にx86を選択する必要があります。

これにより、警告が消え、アセンブリまたはプロジェクトが「任意のCPU」と互換性がなくなったが、x86固有であることが示されます。これは、x64依存関係を持つ64ビットプロジェクトを構築している場合にも当てはまります。代わりにx64を選択するだけです。

もう1つの注意点として、プロジェクトが純粋な.NETプロジェクトである場合、プロジェクトは通常「任意のCPU」と互換性があります。この問題は、特定のプロセッサアーキテクチャを対象とする依存関係（サードパーティのdllまたは独自のC ++マネージプロジェクト）を導入した場合にのみ発生します。

score 153 · Accepted Answer

これは非常に頑固な警告であり、有効な警告ですが、サードパーティのコンポーネントの使用やその他の理由により解決できない場合があります。プロジェクトプラットフォームがAnyCPUであり、AMD64用に構築されたMSライブラリを参照しているため、警告が発生することを除いて、同様の問題が発生します。ちなみに、これはVisual Studio 2010にあり、VS2012と.Net4.5をインストールすることで導入されたようです。

参照しているMSライブラリを変更できず、ターゲットの展開環境が64ビットになることがわかっているため、この問題は無視してかまいません。

警告はどうですか？Microsoftは、Connectレポートに応えて、その警告を無効にするオプションが1つあると投稿しました。これを行う必要があるのは、ソリューションアーキテクチャを十分に認識しており、展開ターゲットを完全に理解しており、開発環境以外の問題ではないことを知っている場合のみです。

プロジェクトファイルを編集し、このプロパティグループと設定を追加して、警告を無効にすることができます。

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

score 67 · Accepted Answer

経験則として、「DLLを開く、EXEを閉じる」、つまり次のようにします。

EXEは、x86またはx64を指定することにより、OSを対象としています。
DLLは開いたまま（つまり、AnyCPU）であるため、32ビットまたは64ビットのプロセス内でインスタンス化できます。

EXEをAnyCPUとしてビルドする場合、実行するのは、OSに使用するプロセスのビット数の決定を延期することだけです。これにより、EXEが好みに合わせてJITされます。つまり、x64 OSは64ビットプロセスを作成し、x86OSは32ビットプロセスを作成します。

DLLをAnyCPUとして構築すると、DLLはどちらのプロセスとも互換性があります。

アセンブリのロードの微妙な点について詳しくは、こちらをご覧ください。エグゼクティブサマリーは次のようになります。

AnyCPU –呼び出しプロセスに応じて、x64またはx86アセンブリとしてロードされます
x86 –x86アセンブリとしてロードします。x64プロセスからロードされません
x64 –x64アセンブリとしてロードします。x86プロセスからロードされません

score 24 · Accepted Answer

C＃DLLは、プラットフォームターゲットx86でセットアップされています

これは一種の問題ですが、DLLは実際にはプロセスのビット数を選択することができません。これはEXEプロジェクトによって完全に決定されます。これは、ロードされる最初のアセンブリであるため、そのプラットフォームターゲット設定は、プロセスのビット数をカウントして設定するものです。

DLLには選択肢がなく、プロセスのビット数と互換性がある必要があります。そうでない場合は、コードで使用しようとすると、BadImageFormatExceptionを伴う大きなKaboomが発生します。

したがって、DLLの適切な選択はAnyCPUであるため、どちらの方法でも機能します。これはC＃DLLにとって非常に理にかなっていますが、どちらの方法でも機能します。ただし、C ++ / CLI混合モードDLLではなく、プロセスが32ビットモードで実行されている場合にのみ正常に機能するアンマネージコードが含まれていることは確かです。ビルドシステムにそれに関する警告を生成させることができます。それはまさにあなたが得たものです。警告だけですが、それでも正しくビルドされます。

問題をパントするだけです。EXEプロジェクトのプラットフォームターゲットをx86に設定します。これは、他の設定では機能しません。そして、すべてのDLLプロジェクトをAnyCPUに保持します。

score 8 · Accepted Answer

私はこれをしたのと同じ警告を受けていました：

プロジェクトのアンロード
プロジェクトのプロパティ、つまり.csprojを編集します

次のタグを追加します。

<PropertyGroup>
    <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
        None
    </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

プロジェクトをリロードします

score 5 · Accepted Answer

私は今日この問題を抱えていましたが、Visual Studioで建物の構成を確認するだけでは、構築されていないプロジェクトと参照されているプロジェクトの両方のCPUが表示されたため役に立ちませんでした。

次に、参照されているプロジェクトのcsprojを調べて、次のことを見つけました。

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x64</PlatformTarget>

どういうわけか、このPlatformTargetは構成変更の途中で追加され、IDEはそれを認識していないようです。

参照されているプロジェクトからこの行を削除すると、問題が解決しました。

score 4 · Accepted Answer

https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-exampleを使用します。

Directory.Build.propsファイルをソリューションフォルダーに追加します
これを貼り付けます：

<Project>
 <PropertyGroup>
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
 </PropertyGroup>
</Project>

score 3 · Accepted Answer

C＃DLLにx86ベースの依存関係がある場合、DLL自体はx86である必要があります。私はそれを回避する方法を本当に見ていません。64ビットの実行可能ファイルは32ビットのライブラリをロードできないため、VSはそれを（たとえば）x64に変更することについて不平を言います。

C++プロジェクトの構成について少し混乱しています。ビルドに提供された警告メッセージは、ターゲットとするプラットフォームが[MSIL]であると報告したため、AnyCPUをターゲットにしたことを示していますが、プロジェクトの構成は実際にはWin32であると示しました。ネイティブのWin32アプリはMSILを使用しないでください。ただし、C＃ライブラリとやり取りする場合は、CLRサポートを有効にする必要があります。ですから、情報面にはいくつかのギャップがあると思います。

プロジェクトの正確な構成とそれらがどのように相互に関連しているかについて、もう少し詳しく確認して投稿していただけますか？可能であれば、さらにサポートさせていただきます。

score 3 · Accepted Answer

BuildDavid Sacksの回答に加えて、のタブに移動して、これらの警告を表示しているプロジェクトにProject Properties設定Platform Targetする必要がある場合もあります。x86ご想像のとおり、この設定は構成マネージャーの設定と完全に同期されていないようです。

score 2 · Accepted Answer

C＃プロジェクトの場合、x86のターゲットはそのように聞こえます。このアセンブリはx86アーキテクチャのみをサポートしていると書かれています。x64についても同様です。一方、CPUはどちらのアーキテクチャでもかまわないと言っていますが、両方をサポートしています。それで、次の2つの質問は（1）これらのdllを使用する実行可能ファイルの構成は何ですか？（2）ビットネスとはあなたのOS/コンピュータの？私が尋ねる理由は、実行可能ファイルが64ビットで実行するようにコンパイルされている場合、64ビットモードでも実行できるようにすべての依存関係が必要だからです。Any CPUアセンブリをロードできるはずですが、x86構成でのみ実行できる他の依存関係を参照している可能性があります。実行可能ファイルを64ビットモードで実行する場合は、すべての依存関係と依存関係をチェックして、すべてが「任意のCPU」または「x64」であることを確認してください。そうしないと、問題が発生します。

多くの点で、Visual Studioでは、CPUとアーキテクチャに依存するさまざまなアセンブリを簡単に組み合わせてコンパイルすることはできません。それは実行可能ですが、依存関係のどこかに2つのバージョンがあるため、そうでなければ「任意のCPU」であるアセンブリをx86とx64用に別々にコンパイルする必要があることがよくあります。

score 1 · Accepted Answer

以前、特にSharePointなどの既存のx64ソリューションにテストソリューションを追加するときに、同様の問題が発生しました。私の場合、特定のプロジェクトテンプレートがデフォルトで特定のプラットフォームとして追加されているという事実に関係しているようです。

これが私にとってよく機能する解決策です：構成マネージャー（アクティブな構成ドロップダウン、通常はデバッグと言います）とプロジェクトプラットフォーム（プロジェクトプロパティ内）ですべてを正しいプラットフォームに設定しますビルドしてから、すべてをAnyCPUに戻します。一部の依存関係（各プロジェクトのプロパティのDLL）を削除して再度追加する必要がある場合や、「32ビットまたは64ビットプロセスでテストを実行する」（Local.testsettingsをダブルクリックしてホストに移動する）を変更する必要がある場合があります。

これは単に何かを設定してから元に戻すことであるように私には思えますが、おそらく私が見ていない舞台裏でもっと多くのことが起こっています。しかし、過去にはかなり一貫して機能していました。

score 1 · Accepted Answer

私のプロジェクトでは、x86とx64の両方にビルドできる必要があります。これに伴う問題は、一方を使用しているときに参照を追加すると、もう一方を作成するときに文句を言うことです。

私の解決策は、*。csprojファイルを手動で編集して次のような行にすることです。

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

これに変更されます：

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

score 1 · Accepted Answer

MSUNITテストDLLが原因で同様の問題が発生しました。私のWPFアプリケーションはx86としてコンパイルされましたが、単体テストDLL（参照されたEXEファイル）は「任意のCPU」としてコンパイルされました。ユニットテストDLLをx86（EXEと同じ）用にコンパイルするように変更し、再解決しました。

score 1 · Accepted Answer

また、f.csprojがコマンドに基づいて構築されているため、解決が容易ではないMSFakesアセンブリに対してこの警告が表示される場合があります。幸いなことに、Fakesxmlを使用するとそこに追加できます。

score 0 · Accepted Answer

ビルドでも非常によく似た警告がありました。私のプロジェクトは.NET4.5をターゲットに設定され、ビルドサーバーにWindows 8.1 SDK（.NET 4.5.1用）がインストールされました。プロジェクトを.NET4.5.1をターゲットに更新した後（私にとっては問題ではありませんでしたが、まったく新しいアプリケーションの場合でした）、警告は表示されなくなりました...

score 0 · Accepted Answer

この警告を解決し、「Configuration Manager」をリリース（混合プラットフォーム）に変更しました。

score 0 · Accepted Answer

SQL Server 2012 SP1 SSISパイプラインスクリプトタスクをコンパイルするときに、SQL Server 2012 SP2をインストールするまで、VisualStudio2012でこの警告が表示されました。

score 0 · Accepted Answer

SQLiteが接続を開くときに同じ問題が発生し、Nugetを使用して、プロジェクトで使用されるコンポーネント（SQLite）をインストールすると修正されました！この方法でコンポーネントをインストールして、結果を確認してください

score 0 · Accepted Answer

ここで答えが見つからない人のために投稿したいだけで、問題は解決しました。

アプリケーションを実行するときは、ソリューションプラットフォームのドロップダウンが正しく設定されていることを確認してください。私はx86を使用していたため、この問題が発生しました。

score -1 · Accepted Answer

.NET EXE / DLL AnyCPUと、それに依存するアンマネージDLLをx86とx64の両方でコンパイルし、両方とも異なるファイル名でバンドルし、.NETモジュールがランタイムに基づいて正しいファイルを動的にロードする方法があるはずです。プロセッサアーキテクチャ。それはAnyCPUを強力にするでしょう。C ++ DLLがx86またはx64のみをサポートしている場合、AnyCPUはもちろん無意味です。しかし、構成マネージャーは、複数のバンドル用に異なる構成/プラットフォームで同じプロジェクトを2回ビルドする手段さえ提供しておらず、AnyCPUやその他の構成のような概念を可能にするため、両方のアイデアをバンドルすることはまだ実装されていません。

.net - Visual Studioのコンパイルエラー「プロセッサアーキテクチャ間の不一致」を修正するにはどうすればよいですか？

20 に答える 20

Related

Reference