.net 在x64上生成VC++项目,无法在x86上执行
我有一个非托管VC++项目,可以为x86和x64目标构建。它被为任何CPU编译的.NET程序使用。这是在VS2010上,但在使用VS2008和vcbuild构建解决方案时,我遇到了相同的问题 以下是我的构建脚本中的构建命令:.net 在x64上生成VC++项目,无法在x86上执行,.net,visual-studio-2010,visual-c++,msbuild,.net,Visual Studio 2010,Visual C++,Msbuild,我有一个非托管VC++项目,可以为x86和x64目标构建。它被为任何CPU编译的.NET程序使用。这是在VS2010上,但在使用VS2008和vcbuild构建解决方案时,我遇到了相同的问题 以下是我的构建脚本中的构建命令: msbuild .\Project.vcxproj /t:Build /p:PlatformToolset=v100 /p:Configuration=Release /p:Platform=%platform% 如果构建在x86机器上,且%platform%=Win32
msbuild .\Project.vcxproj /t:Build /p:PlatformToolset=v100 /p:Configuration=Release /p:Platform=%platform%
如果构建在x86机器上,且%platform%=Win32,则所有内容都可以正常构建和执行
如果在x64机器上生成,且%platform%=x64,则所有内容都可以正常生成和执行
但是,如果我在x64机器上构建,并且%platform%=Win32,那么它将成功构建,没有错误。但是,当我将这些假定为-x86的二进制文件复制到x86机器时,它们会导致以下错误:
System.Runtime.InteropServices.SEHException was caught
Message=External component has thrown an exception.
将错误追溯回C++ DLL,在这行上失败:
if ( FAILED( g_Connection.CreateInstance( _T("ADODB.Connection") ) ) )
ThrowException(_T("Cannot create connection."));
我已经查看了我的.vcxproj文件以查找问题,但所有内容似乎都是正确的。没有导入的属性文件或自定义生成任务或类似的内容
这会导致问题,因为我们正试图使用单个x64构建服务器为两个平台创建构建。我们当前的解决方案涉及在两台不同的机器上预先构建C++ DLL。p> 我将问题追溯到这一行,它巧妙地隐藏在一个头文件中:
#import "C:\Program Files\Common Files\System\ado\msado15.dll" no_namespace rename("EOF","EndOfFile")
在x64机器上构建时,无论构建目标平台是什么,都会始终将x86 dll与x64版本的msdado15.dll链接
我通过将两种平台的ADO文件复制到我的项目目录中,并更新项目和标题来解决此问题:
#import "msado15.dll" no_namespace rename("EOF","EndOfFile")
.vcxproj文件:仅显示相关行
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ClCompile>
<AdditionalIncludeDirectories>.\ado\Win32;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ClCompile>
<AdditionalIncludeDirectories>.\ado\x64;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
</ItemDefinitionGroup>
在X86机器上尝试运行时,您能发布您所获得的运行时错误吗?显然,它们无法加载。在仔细查看之后,它抛出了SEHExtRebug,因此看起来好像C++的DLL正在被正确加载,但抛出了一个异常,创建了一个对象。我认为这是一个依赖性问题,而不是C++ DLL本身的问题。