.net - net学习 - visual studio community是什么




如何修复Visual Studio编译错误,“处理器体系结构之间的不匹配”? (12)

C#DLL使用平台目标x86进行设置

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

DLL没有选择,它们需要与进程位相兼容。 如果他们不是,那么当你的代码尝试使用它们时,你会得到一个带有BadImageFormatException的大型Kaboom。

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

只是解决问题。 将EXE项目的Platform目标设置为x86,它不会与任何其他设置一起使用。 只要将所有DLL项目保存在AnyCPU中。

我对Visual Studio 2010中的项目配置很陌生,但我已经做了一些research ,但仍然无法完全解决这个问题。 我有一个C ++ DLL引用C#DLL的Visual Studio解决方案。 C#DLL引用了一些其他的DLL,一些在我的项目和一些外部。 当我尝试编译C ++ DLL时,出现以下警告:

警告MSB3270:构建“MSIL”的项目的处理器体系结构与参考“[internal C#dll]”,“x86”的处理器体系结构之间存在不匹配。

它告诉我去配置管理器来调整我的架构。 C#DLL使用平台目标x86进行设置。 如果我尝试将其更改为其他任何内容,如Any CPU,则会发生抱怨,因为依赖的其中一个外部DLL具有平台目标x86。

当我查看配置管理器时,它将我的C#DLL的平台显示为x86,并将我的C ++项目显示为Win32。 这似乎是正确的设置; 当然,我不希望我的C ++项目的项目将平台设置为x64,这是唯一提供的其他选项。

我在这里做错了什么?


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

  • EXE通过指定x86或x64来定位操作系统。
  • DLL保持开放(即AnyCPU),因此它们可以在32位或64位进程中实例化。

当您将EXE构建为AnyCPU时,您所做的只是推迟关于在OS上使用哪种进程位数的决定,这将根据EXE的喜好进行调整。 也就是说,一个x64操作系统将创建一个64位进程,一个x86操作系统将创建一个32位进程。

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

有关装配加载细节的更多信息,请参见here 。 执行摘要如下所示:

  • AnyCPU - 根据调用过程加载为x64或x86程序集
  • x86 - 作为x86程序集加载; 将不会从x64进程加载
  • x64 - 加载为x64程序集; 将不会从x86进程加载

对于C#项目,x86的目标听起来很像。 它说这个程序集只支持x86体系结构。 同样适用于x64。 另一方面,任何CPU都表示我不关心哪个体系结构,我同时支持这两种体系结构。 所以,接下来的两个问题是(1)使用这些dll的可执行文件的配置是什么? 和(2)你的OS /计算机的位数是多少? 我问的原因是因为如果您的可执行文件被编译为64位运行,那么它需要所有的依赖关系能够以64位模式运行。 你的任何CPU程序集都应该能够被加载,但也许它正在引用一些只能在x86配置下运行的其他依赖。 如果您打算以64位模式运行可执行文件,请检查所有依赖项和依赖关系以确保所有内容都是“任意CPU”或“x64”。 否则,你会遇到问题。

在许多方面,Visual Studio不会轻松编译任何CPU和各种体系结构相关程序集的混合。 这是可行的,但它通常需要一个组件,否则就是“任何CPU”必须分别编译为x86和x64,因为某些依赖项的某个依赖项有两个版本。


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

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

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


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

以下是我经常使用的解决方案:在Configuration Manager中将所有内容设置到正确的平台(活动配置下拉菜单,通常称为调试是一种很好的方法)和项目平台(在项目属性中),然后构建,然后将所有内容都设置回AnyCPU。 有时我必须删除并重新添加一些依赖项(每个项目属性中的DLL),有时需要更改“以32位或64位进程运行测试”(双击Local.testsettings并转到主机)。

在我看来,这只是设置一些东西然后放回去的,但是我可能在幕后发生了更多事情,我没有看到。 尽管如此,它对我来说仍然是一贯的。


我有与SQLite打开连接相同的问题,并使用Nuget和安装项目中使用的组件(SQLite)修复它! 尝试以这种方式安装组件并检查结果


我有类似的问题,它是由MS单元测试DLL引起的。 我的WPF应用程序被编译为x86,但单元测试DLL(引用的EXE文件)为“任何CPU”。 我将单元测试DLL更改为x86编译(与EXE相同),并将其解压缩。


我解决了这个警告,将“Configuration Manager”更改为Release(混合Plataform)。



这个警告似乎是在新的Visual Studio 11 Beta和.NET 4.5中引入的,尽管我想这可能是以前可能的。

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

  1. 转到Build | Configuration Manager菜单项。
  2. 在列表中找到你的项目,在平台下,它会说“任何CPU”
  3. 从下拉列表中选择“Any CPU”选项,然后选择<New..>
  4. 在该对话框中,从“New Platform”下拉列表中选择x86,并确保在“Copy settings from”下拉列表中选择“Any CPU”。
  5. 点击确定
  6. 您将要为Debug和Release配置选择x86。

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

还有一点需要注意的是,如果项目是纯.NET项目,项目通常可以兼容“任何CPU”。 如果你引入了一个针对特定处理器体系结构的依赖关系(第三方dll或你自己的C ++托管项目),那么这个问题才会出现。


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

由于我无法更改引用的MS库,并且由于我知道我的目标部署环境只能是64位,所以我可以放心地忽略此问题。

那警告呢? 微软发布了一篇关于连接报告的回应,其中一个选项是禁用该警告。 你只应该这样做,你是非常了解你的解决方案架构,并且你完全理解你的部署目标,并且知道这不是开发环境之外的问题。

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

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




visual-studio