#.net #visual-studio-2010 #visual-c #msbuild
#.net #visual-studio-2010 #visual-c #msbuild
Вопрос:
У меня есть неуправляемый проект VC , который я могу создать как для целей x86, так и для целей x64. Он используется программой .NET, которая скомпилирована для любого процессора. Это на VS2010, но у меня была такая же проблема, когда решение было построено с помощью VS2008 и vcbuild.
Вот команда сборки в моем скрипте сборки:
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 для создания сборок для обеих платформ. Наш текущий обходной путь включает предварительную сборку библиотеки DLL C на двух разных машинах.
Комментарии:
1. Не могли бы вы опубликовать ошибку времени выполнения, которую вы получаете при попытке запуска на компьютере x86?
2. по-видимому, «они не могут быть загружены».
3. При ближайшем рассмотрении он выдает исключение SEHException, поэтому похоже, что C dll загружается правильно, но выдает исключение, создающее объект. Я думаю, что это проблема зависимости, а не проблема с самой C dll.
Ответ №1:
Я проследил проблему до этой строки, хитроумно скрытой в одном из заголовочных файлов:
#import "C:Program FilesCommon FilesSystemadomsado15.dll" no_namespace rename("EOF","EndOfFile")
Это всегда будет связывать x86 dll с x64 версией msdado15.dll при сборке на компьютере x64 — независимо от целевой платформы сборки.
Я решил проблему, скопировав файлы ADO для обеих платформ в свой каталог проекта и обновив проект и заголовок:
#import "msado15.dll" no_namespace rename("EOF","EndOfFile")
файл .vcxproj: (показаны только соответствующие строки)
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ClCompile>
<AdditionalIncludeDirectories>.adoWin32;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ClCompile>
<AdditionalIncludeDirectories>.adox64;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
</ItemDefinitionGroup>