Возможно ли, что на взаимодействие COM влияет процесс размещения Visual Studio?

Question

У меня проблемы с запуском 32-разрядного приложения .NET в Windows 7 x64, которое, кажется, сосредоточено вокруг сторонней библиотеки COM. Вот настройки:

Наше приложение было написано для 32-битной Windows XP, но мы пытались настроить его так, чтобы оно нормально работало на 64-битной Windows. Он основан на P / Invoke и COM Interop с несколькими 32-битными сторонними библиотеками. Получение 64-битных версий этих библиотек невозможно.

Данная библиотека представляет собой оболочку COM, предоставляемую поставщиком для своей библиотеки на основе C (не поддерживается в Windows XP). С этим интерфейсом гораздо проще работать из .NET. Однако в 64-битной Windows 7 библиотека COM, кажется, работает со сбоями во время своей инициализации. Фреймворк имеет функцию с именем Init (), которая возвращается с успехом, но впоследствии она не ведет себя «должным образом».

Фреймворк должен искать информацию о конфигурации в реестре во время инициализации (имена созданных нами пользовательских библиотек DLL и другие метаданные). Используя Sysinternals Process Monitor, я вижу, что он запрашивает информацию в разделе о 32-битной совместимости реестра, но, похоже, он не использует , что находит.

Я могу воспроизвести это поведение, взаимодействуя с интерфейсом COM из PowerShell (x86), поэтому я не думаю, что у меня неправильная настройка в Visual Studio.

Вот кикер, хотя. Если я запускаю наше приложение на платформе x64 из Visual Studio с включенным процессом хостинга, оно работает каждый раз. Если я отключаю процесс хостинга или запускаю извне Visual Studio, он каждый раз завершается сбоем.

Есть какие-нибудь идеи о размещенной среде, которая позволяет этому взаимодействию COM преуспеть?

ОБНОВЛЕНИЕ: приложение определенно работает в 32-битном режиме. Visual Studio настроена на сборку для x86, и я вижу * 32 после его имени в диспетчере задач. Process Monitor также показывает используемые библиотеки WOW64.

Answer 1

Вы не можете загрузить 32-битные DLL в 64-битный процесс (и наоборот). Если у вас есть приложение, которое использует DLL, которая упаковывает и загружает другую DLL и т. Д., Все DLL в цепочке ДОЛЖНЫ быть 64-битными для загрузки. Если одна из библиотек DLL является 32-разрядной, она не будет загружаться, и ваше приложение, скорее всего, выйдет из строя.

Поскольку вы зависите от этих 32-битных библиотек DLL, вероятно, лучше всего пометить все ваши EXE-файлы как 32-битные. Вы можете оставить свои собственные DLL-библиотеки способными поддерживать 32-разрядную или 64-разрядную версию, но, ограничивая свои EXE-файлы только 32-разрядными, вы также принудительно заставите все загруженные ресурсы использовать 32-разрядные.

Была ли какая-то конкретная причина, по которой вы переносили свое приложение на 64-разрядную версию?

Answer 2

Одно из отличий состоит в том, что процесс размещения визуальной студии статически не зависит от вашего кода. Сначала он запускается, загружается .net, создается appdomain, а затем загружается ваш .exe, как если бы это была dll.

Если это ключевое отличие, то вы сможете запустить приложение вне отладчика, реплицировав этот сценарий. Создайте фиктивный .net exe-файл, который ничего не делает, кроме запуска, а затем динамически загрузите dll, которая содержит реальную программу.

Это может приблизить вас к пониманию / решению проблемы, поскольку исключает другие проблемы и позволяет вам исходить из того, что работает.