我是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,这是唯一的其他选项。

我哪里做错了?


当前回答

我得到的警告和我做的一样

卸载项目 编辑项目属性,即。csproj 添加以下标签: < PropertyGroup > < ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch > 没有一个 < / ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch > < / PropertyGroup > 重新加载项目

其他回答

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实际上无法选择进程的比特数。这完全由EXE项目决定,这是加载的第一个程序集,所以它的平台目标设置是为进程计数和设置位。

dll没有选择,它们需要与进程位相兼容。如果它们不是,那么当你的代码试图使用它们时,你会得到一个大的爆炸和BadImageFormatException。

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

把这个问题撇在一边。将EXE项目的平台目标设置为x86,它将无法与任何其他设置一起工作。并将所有DLL项目保存在AnyCPU中。

如果你的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.

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

我以前遇到过类似的问题,特别是在向现有的x64解决方案(如SharePoint)添加测试解决方案时。在我的例子中,这似乎与默认情况下某些项目模板被添加为某些平台有关。

Here's the solution that often works for me: set everything to the correct platform in the Configuration Manager (the active configuration drop-down, says Debug normally, is a good way to get to it) and project platform (in project properties), then build, then set everything back to AnyCPU. Sometimes I have to remove and re-add some dependencies (DLLs in each project's Properties) and sometimes the "Run tests in 32 bit or 64 bit process" (double-click Local.testsettings and go to Hosts) has to be changed.

在我看来,这只是设定了一些事情,然后又把它放回去,但在幕后可能有更多我没有看到的事情发生。不过在过去,这对我来说是相当稳定的。

在我的构建中,我遇到了非常类似的警告。我的项目被设置为。net 4.5,在构建服务器上安装了Windows 8.1 SDK(用于。net 4.5.1)。在将我的项目更新到。net 4.5.1之后(对我来说不是问题,对于一个全新的应用程序来说),我再也没有收到警告了……