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

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

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

構成を調整するためにConfiguration Managerに移動するよう指示されます。C＃DLLは、プラットフォームターゲットx86でセットアップされます。私は、任意のCPUのように、何か他のものに変更しようとした場合、外部のDLLの1ので、それは文句を言う、それが依存するが、プラットフォームターゲットx86のを持っています。

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

ここで何が悪いのですか？

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

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

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

これにより、警告が表示されなくなり、アセンブリまたはプロジェクトが「Any CPU」互換ではなくなり、x86固有になったことが示されます。これは、x64に依存する64ビットプロジェクトをビルドする場合にも当てはまります。代わりにx64を選択するだけです。

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

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

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

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

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

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

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

• EXEは、x86またはx64を指定して、OSをターゲットにします。
• DLLは開いたまま（つまりAnyCPU）なので、32ビットまたは64ビットプロセス内でインスタンス化できます。

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

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

アセンブリの読み込みの詳細については、こちらを参照してください。エグゼクティブサマリーは次のようになります。

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

C＃DLLがプラットフォームターゲットx86でセットアップされている

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

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

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

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

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

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

3. 次のタグを追加します。

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

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

今日この問題があり、ビルドしていないプロジェクトと参照プロジェクトの両方にCPUが表示されたため、Visual Studioでビルド構成を確認しても役に立たなかった。

次に、参照されたプロジェクトの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はそれを認識していないようでした。

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

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

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

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

David Sacksの回答に加えて、のBuildタブに移動して、これらの警告を出しているプロジェクトにProject Properties設定Platform Targetする必要がある場合もありx86ます。予想どおりかもしれませんが、この設定は構成マネージャーの設定と完全に同期しているようには見えません。

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

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

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

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

これは何かを設定した後に設定し直しているように見えますが、おそらく私が目にしていない舞台裏でさらに多くのことが起こっています。でも、過去には、私にはかなり一貫して働いていました。

私のプロジェクトでは、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"/>

MS UNITテストDLLによって引き起こされた同様の問題がありました。私のWPFアプリケーションはx86としてコンパイルされましたが、ユニットテストDLL（参照されたEXEファイル）は「任意のCPU」として。ユニットテストDLLをx86（EXEと同じ）用にコンパイルするように変更し、再解決しました。

また、MS Fakesアセンブリに対してこの警告が表示される場合がありますが、f.csprojはコマンドに基づいて構築されているため、簡単に解決できません。幸いなことに、Fakes xmlでは、そこに追加できます。

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

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

この警告を解決して、「構成マネージャー」を「リリース（混合プラットフォーム）」に変更しました。

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

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

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

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

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