Почему я могу вызвать 32-битную библиотеку COM из веб-приложения AnyCPU .NET, работающего в IIS7 в 64-битном режиме?

Question

Без использования прокси-службы COM + я вполне могу использовать классы из 32-битной библиотеки COM-взаимодействия из приложения .NET, скомпилированного с целевым AnyCPU, работающего в 64-битном процессе w3wp.

Я успешно создаю экземпляры классов из 32-битной библиотеки COM-взаимодействия в 64-битном .NET-процессе.

w3wp работает в 64-битном режиме, а конфигурация IIS настроена так, чтобы не разрешать 32-битные приложения.Кроме того, фактом является то, что существует специально скомпилированная и зарегистрированная сборка .NET x64.

Мне просто интересно, как это вообще возможно?

Интересно, чтоэто прекрасно работает, если код скомпилирован с Visual Studio 2008 с ориентацией на платформу 3.5.Если тот же код скомпилирован с Visual Studio 2010 с ориентацией на платформу 3.5, приложение неожиданно завершает работу при попытке загрузить 32-битную библиотеку COM-взаимодействия.Как и должно быть.

Answer 1

Он будет работать в 32-битном режиме, если он вообще работает, вы не можете иметь 32-битные компоненты в 64-битном процессе и наоборот.Процесс полностью один или другой.

Это не то же самое, что запуск 32-битного процесса на 64-битном хосте, очевидно, это работает.

Другой альтернативой является то, что сторонний материалфактически предоставляет 64-битную ссылку, и ваш вывод о том, что он работает с 32-битной ошибкой.

Answer 2

Я объясню это до некоторой сложности в тоннах кода и проектов, из которых состоит решение. Снятие требований к 64-битной библиотеке, создающей проблемы, решило проблему, но, естественно, не отвечает на этот вопрос. Это просто делает его устаревшим.

Answer 3

Процесс w3wp может работать в 32-битном режиме и, следовательно, может обрабатывать 32-битные сборки. Проверьте, работает ли ваша служба IIS в 32-разрядном режиме.

Answer 4

Вы. Являются. Не.

Point.

Переведите веб-приложение в 32-битный режим. Это на самом деле, как они должны работать в соответствии с руководящими принципами MS IIS (что большинство людей никогда не удосужились прочитать).

Answer 5

Он работает через механизм DllSurrogate, который автоматически создает процесс DllHost, когда вы пытаетесь загрузить код неправильной битности.В этих случаях вы получаете неявное межпроцессное взаимодействие.Просто взгляните на главную.