Это очень странно.
У нас есть некоторый управляемый C ++ (сборка), который использует .NET COM-взаимодействие dll, сгенерированное TlbImp, для выполнения вызовов в COM-объект. Когда мы регистрируем COM DLL, мы указываем, что мы хотим, чтобы она выполнялась в суррогате (запись реестра «DLLSurrogate»).
Наша COM-библиотека является 64-разрядной и работает на 64-разрядной платформе.
Когда мы интегрируем сборку с 32-разрядным приложением (которое содержит управляемый и неуправляемый код), вызовы в библиотеку COM выполняются в DllHost. 64-битная сборка того же приложения приводит к тому, что вызовы выполняются в вызывающем процессе.
Чистые неуправляемые клиентские приложения (как 32, так и 64-разрядные) работают правильно в 64-разрядной системе, что показывает (я надеюсь), что мы правильно настроили / установили библиотеку COM.
Это может указывать на то, что .NET COM Interop игнорирует информацию о конфигурации в реестре. 32-битный клиент не может загрузить 64-битную COM DLL в свое адресное пространство и по умолчанию использует суррогат? В любом случае, такое поведение для нас губительно, поскольку библиотека COM содержит одноэлементный доступ к некоторому оборудованию и, возможно, множество клиентских процессов.
Кто-нибудь отмечал это поведение раньше?
Спасибо
Майк Д