我是Visual Studio 2010项目配置的新手,但我做了一些研究,仍然不能完全解决这个问题。我有一个Visual Studio解决方案的c++ DLL引用c# DLL。c# DLL引用了一些其他DLL,一些在我的项目内,一些在外部。当我试图编译c++ DLL时,我得到这个警告:

警告MSB3270:正在构建的“MSIL”项目的处理器架构与参考“[内部c# dll]”,“x86”的处理器架构之间不匹配。

它告诉我去配置管理器调整我的架构。c# DLL是用目标平台x86建立的。如果我尝试将其更改为其他东西,如任何CPU,它会抱怨,因为它所依赖的外部dll之一具有平台目标x86。

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

我哪里做错了?


当前回答

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

因为我不能更改我引用的MS库,而且我知道我的目标部署环境永远只能是64位的,所以我可以安全地忽略这个问题。

那警告呢?微软在回应一份Connect报告时表示,一种选择是禁用该警告。只有在非常了解自己的解决方案体系结构、完全理解部署目标并知道在开发环境之外这不是真正的问题时,您才应该这样做。

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

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

其他回答

一个好的经验法则是“打开dll,关闭ex”,也就是说:

EXE的目标操作系统,通过指定x86或x64。 dll是开放的(即AnyCPU),因此可以在32位或64位进程中实例化它们。

当您将EXE构建为AnyCPU时,您所做的一切都是将使用哪个进程位的决定推迟到操作系统,这将JIT EXE到它喜欢的程度。也就是说,x64操作系统将创建64位进程,x86操作系统将创建32位进程。

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

有关程序集加载的更多细节,请参见这里。执行摘要如下所示:

AnyCPU -加载为x64或x86程序集,取决于调用进程 X86 -加载为X86汇编;不能从x64进程加载 X64 -加载为X64程序集;不能从x86进程加载

我只是把平台目标从属性改为“任何CPU”,就完成了! 也许你应该创建一个发布版本。

这样做:

我在Visual Studio 2012编译SQL Server 2012 SP1 SSIS管道脚本任务时得到了这个警告-直到我安装了SQL Server 2012 SP2。

There should be a way to make a .NET EXE/DLL AnyCPU, and any unmanaged DLLs it depends on compiled both with x86 and x64, both bundled perhaps with different filenames and then the .NET module dynamically loading the correct one based on its runtime processor architecture. That would make AnyCPU powerful. If the C++ DLL only supports x86 or x64 then AnyCPU is of course pointless. But the bundling both idea I have yet to see implemented as the configuration manager does not even provide a means to build the same project twice with a different configuration/platform for multiple bundling allowing AnyCPU or even other concepts like any configuration to be possible.

如果你的c# DLL有基于x86的依赖关系,那么你的DLL本身就必须是x86的。我真不知道还有什么办法。VS抱怨将其更改为(例如)x64,因为64位可执行文件无法加载32位库。

I'm a little confused about the configuration of the C++ project. The warning message that was provided for the build suggests that it was targeted for AnyCPU, because it reported the platform that it targeted was [MSIL], but you indicated that the configuration for the project was actually Win32. A native Win32 app shouldn't involve the MSIL - although it would likely need to have CLR support enabled if it is interacting with a C# library. So I think there are a few gaps on the information side.

我能否恭敬地请您回顾并发布更多关于这些项目的确切配置以及它们是如何相互关联的细节?如有可能,我很乐意进一步提供帮助。