Question

我是Visual Studio 2010中的项目配置的新手，但我已经做了一些research，但仍然无法解决这个问题。我有一个Visual Studio解决方案，其中包含引用C＃DLL的C ++ DLL。 C＃DLL引用了一些其他的DLL，一些在我的项目中，一些在外部。当我尝试编译C ++ DLL时，我收到此警告：

警告MSB3270：正在构建“MSIL”的项目的处理器体系结构与参考“[internal C＃dll]”，“x86”的处理器体系结构不匹配。

它告诉我转到Configuration Manager来调整我的架构。 C＃DLL使用平台目标x86进行设置。如果我尝试将其更改为其他内容，例如Any CPU，则会抱怨，因为其中一个外部DLL it 依赖于平台目标x86。

当我查看Configuration Manager时，它将我的C＃DLL平台显示为x86，将我的C ++项目显示为Win32。这似乎是正确的设置;当然我不希望我的C ++项目的项目将平台设置为x64，这是唯一提供的其他选项。

我在这里做错了什么？

Answer 1

这个警告似乎是在新的Visual Studio 11 Beta和.NET 4.5中引入的，尽管我认为它之前可能已经存在过。

首先，它只是一个警告。如果您只是处理x86依赖项，它不应该伤害任何东西。当您声明您的项目与“任何CPU”兼容但您依赖于x86或x64的项目或.dll程序集时，Microsoft只是试图警告您。因为您具有x86依赖性，所以从技术上讲，您的项目不是“任何CPU”兼容的。要使警告消失，您实际上应该将项目从“任何CPU”更改为“x86”。这很容易做到，这是步骤。

转到Build | Configuration Manager菜单项。
在列表中找到您的项目，在平台下将显示“任何CPU”
从下拉列表中选择“任何CPU”选项，然后选择<New..>
从该对话框中，从“新平台”下拉列表中选择x86，并确保在“从以下位置复制设置”下拉列表中选择“任何CPU”。
点击确定
您需要为调试和发布配置选择x86。

这将使警告消失，并声明您的程序集或项目现在不再与“任何CPU”兼容，但现在特定于x86。如果要构建具有x64依赖性的64位项目，这也适用;你只需要选择x64。

另外需要注意的是，如果项目是纯.NET项目，项目通常可以兼容“任何CPU”。如果您引入了针对特定处理器体系结构的依赖项（第三方DLL或您自己的C ++托管项目），则只会出现此问题。

Answer 2

这是一个非常顽固的警告，虽然这是一个有效的警告，但在某些情况下由于使用第三方组件和其他原因而无法解决。我有一个类似的问题，除了警告是因为我的项目平台是AnyCPU，我正在引用为AMD64构建的MS库。顺便说一句，这是在Visual Studio 2010中，并且似乎是通过安装VS2012和.Net 4.5来引入的。

由于我无法更改我正在引用的MS库，并且因为我知道我的目标部署环境将只是64位，所以我可以放心地忽略这个问题。

警告怎么样？微软在回复a Connect report时发布了一个选项是禁用该警告。您应该这样做，因为您非常了解您的解决方案体系结构，并且您完全了解您的部署目标，并且知道它在开发环境之外并不是真正的问题。

您可以编辑项目文件并添加此属性组并设置为禁用警告：

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

Answer 3

一个好的经验法则是“打开DLL，关闭的EXE”，即：

EXE 通过指定x86或x64来定位操作系统。
DLL 保持打开状态（即AnyCPU），因此可以在32位或64位进程中实例化它们。

当您将EXE构建为AnyCPU时，您所做的就是推迟决定使用哪个进程位来操作系统，这将使EXE符合它的喜好。也就是说，x64操作系统将创建一个64位进程，x86操作系统将创建一个32位进程。

将DLL构建为AnyCPU使它们与任一进程兼容。

有关装配加载的细微之处的更多信息，请参阅here。执行摘要的内容如下：

AnyCPU - 加载为x64或x86程序集，具体取决于调用过程
x86 - 加载为x86程序集;不会从x64进程加载
x64 - 加载为x64程序集;将不会从x86进程加载

Answer 4

使用平台目标x86设置C＃DLL

这是一个问题，DLL实际上并没有选择进程的位数。这完全取决于EXE项目，它是第一个加载的程序集，因此它的平台目标设置是计算和设置进程位数的设置。

DLL没有选择，它们需要与进程位数兼容。如果它们不存在，那么当您的代码尝试使用BadImageFormatException时，您将获得一个大的Kaboom。

因此，对于DLL的一个很好的选择是AnyCPU，因此它们可以以任何方式工作。这对C＃DLL很有意义，它们做以任何方式工作。但可以肯定的是，它不是您的C ++ / CLI混合模式DLL，它包含非托管代码，只有在进程以32位模式运行时才能正常运行。你可以让构建系统生成有关它的警告。这正是你得到的。只是警告，它仍然正确构建。

解决问题。将EXE项目的平台目标设置为x86，它不能与任何其他设置一起使用。并将所有DLL项目保留在AnyCPU。

Answer 5

我今天遇到了这个问题，只是在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似乎没有看到它。

从引用的项目中删除此行解决了我的问题。

Answer 6

除了David Sacks的回答之外，您可能还需要转到Build的{{1}}标签，并将Project Properties设置为Platform Target以获取正在提供的项目你这些警告。虽然您可能期望它，但此设置似乎与配置管理器中的设置不完全同步。

Answer 7

我得到了同样的警告：

卸载项目
编辑项目属性，即.csproj

添加以下标记：

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

重新加载项目

Answer 8

如果您的C＃DLL具有基于x86的依赖项，那么您的DLL本身将必须是x86。我真的没有办法解决这个问题。 VS抱怨将其更改为（例如）x64，因为64位可执行文件无法加载32位库。

我对C ++项目的配置有点困惑。为构建提供的警告消息表明它是针对AnyCPU的，因为它报告了它所针对的平台是[MSIL]，但是您指出该项目的配置实际上是Win32。原生Win32应用程序不应涉及MSIL - 尽管如果它与C＃库交互，可能需要启用CLR支持。所以我认为信息方面存在一些差距。

我是否可以恭敬地请您查看并发布项目确切配置的详细信息以及它们之间的相互关系？如果可能的话，很乐意进一步提供帮助。

Answer 9

对于C＃项目，x86的目标听起来像它。它说这个程序集只支持x86架构。同样适用于x64。另一方面，任何CPU都说我不关心哪种架构，我支持这两种架构。那么，接下来的两个问题是（1）使用这些dll的可执行文件的配置是什么？（2）您的操作系统/计算机的位数是什么？我问的原因是因为如果您的可执行文件被编译为以64位运行，那么它需要所有依赖项以便能够以64位模式运行。您的Any CPU程序集应该能够加载，但它可能引用了一些只能在x86配置中运行的其他依赖项。检查所有依赖项和依赖项依赖项，以确保在计划以64位模式运行可执行文件时，所有内容都是“任何CPU”或“x64”。否则，你会遇到问题。

在许多方面，Visual Studio不会简单地编译Any CPU和各种架构相关程序集的混合体。它是可行的，但它通常要求一个组件，否则将是“任何CPU”必须为x86和x64单独编译，因为某些依赖依赖有两个版本。

Answer 10

对于我的项目，我需要能够构建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"/>

Answer 11

我有类似的问题，它是由MS UNIT Test DLL引起的。我的WPF应用程序编译为x86但单元测试DLL（引用的EXE文件）为＆＃34;任何CPU＆＃34;。我改变了单元测试DLL以便为x86编译（与EXE相同）并且它被重新安装。

Answer 12

您可能也会收到MS Fakes程序集的警告，因为f.csproj是基于命令构建的，因此不易解析。幸运的是the Fakes xml allows you to add it in there。

Answer 13

之前我遇到过类似的问题，特别是在将测试解决方案添加到现有x64解决方案（如SharePoint）时。就我而言，它似乎与某些项目模板默认添加为某些平台这一事实有关。

以下是经常适用于我的解决方案：在Configuration Manager中将所有内容设置为正确的平台（活动配置下拉列表，通常是Debug，这是一种很好的方式）和项目平台（在项目属性中）），然后构建，然后将所有内容设置回AnyCPU。有时我必须删除并重新添加一些依赖项（每个项目的属性中的DLL），有时必须更改“在32位或64位进程中运行测试”（双击Local.testsettings并转到Hosts）。 / p>

在我看来，这只是设置一些东西，然后将其设置回来，但可能还有更多我在后面看不到的事情。过去，它对我来说相当一致。

Answer 14

应该有一种方法可以创建一个.NET EXE / DLL AnyCPU，以及它依赖于使用x86和x64编译的任何非托管DLL，它们可能捆绑了不同的文件名，然后.NET模块动态加载正确的一个在其运行时处理器架构上。这将使AnyCPU变得强大。如果C ++ DLL只支持x86或x64，那么AnyCPU当然是没有意义的。但捆绑这两个想法我还没有看到实现为配置管理器甚至没有提供一种方法来构建相同的项目两次使用不同的配置/平台进行多个捆绑，允许AnyCPU甚至其他概念，如任何配置都可能。 / p>

Answer 15

我的构建中发出了非常类似的警告。我的项目设置为.NET 4.5，在构建服务器上安装了Windows 8.1 SDK（适用于.NET 4.5.1）。将我的项目更新为目标.NET 4.5.1（对我来说不是一个问题，是一个全新的应用程序），我再也没有收到警告......

Answer 16

我解决了这个警告更改＆＃34;配置管理器＆＃34;发布（混合平台）。

Answer 17

在编译SQL Server 2012 SP1 SSIS管道脚本任务时，我在Visual Studio 2012中收到此警告 - 直到我安装SQL Server 2012 SP2。

Answer 18

我遇到了与SQLite打开连接相同的问题，并使用Nuget并安装了项目中使用的组件（SQLite）修复了它！尝试以这种方式安装组件并检查结果

Answer 19

使用https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example：

将 Directory.Build.props 文件添加到您的解决方案文件夹
将其粘贴到其中：

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

Answer 20

只是想为那些在这里找不到答案的人发帖解决问题。

运行应用程序时，请确保正确设置了解决方案平台下拉菜单。我的是在x86上，这又导致了我这个问题。

如何修复Visual Studio编译错误，“处理器架构之间不匹配”？

20 个答案: