Запуск управляемых служб .Net COM + параллельно в IIS6.0

Question

У нас есть управляемый компонент .Net COM +, который наследуется от ServicedComponent, и мы пытаемся использовать его в качестве параллельной сборки из веб-приложения в IIS 6.0 на Windows Server 2003.

Мысгенерировал манифест сборки с помощью mt.exe и успешно запустил его в параллельном режиме в тестовом консольном приложении.Однако, когда дело доходит до IIS, он просто не работает и вместо чтения манифеста выходит из реестра, пытаясь найти там приложение COM +.

Манифест генерируется с использованием mt.exe -managedassemblyname:myassembly.dll -out:myassembly.manifest, чтозатем скопировали в виртуальный каталог веб-приложения.Использование filemon показывает, что манифест даже не читается!

Перемещение файла .manifest в каталог bin кажется, что оно читается, но возникает та же проблема.

Помощь от любого, кто успешно получил эту работу, будет принята с благодарностью

Answer 1

Внешние манифесты, оканчивающиеся на ".manifest", автоматически выбираются только для исполняемых файлов.Поэтому вы должны сообщить IIS или Windows о своем манифесте, или никто не потрудится прочитать его.

Предположительно, при тестировании вашего консольного приложения манифест исполняемого файла содержит ссылку на MyAssembly или содержал соответствующую информацию напрямую.

Теперь я не очень знаком с ServicedComponent здесьтак что я собираюсь поговорить в общих чертах.

1. Если вам удастся контролировать все программное обеспечение, которое вызывает MyAssembly, вы можете сознательно сначала загрузить информацию в манифест, активироватьэту информацию в поток, позвоните в MyAssembly и деактивировать.Это лучший способ удовлетворить этот вид архитектуры плагинов, потому что вы не загрязняете родительский процесс, вы только конфигурируете поток, в котором работает ваш код, на время работы кода.Этот подход осуществляется посредством вызова API контекста активации, из которых вы можете найти несколько замечательных примеров в бесплатных регистрационных примерах COM в комплекте с All-in One Code Framework
2. Если выне удается контролировать весь код, вызывающий в MyAssembly (если он вызывается автоматически IIS) или если он вызывается в слишком многих местах, а предложенный выше подход слишком дорог, вы всегда можете попробовать здесь «взломать»,Возьмите исполняемый файл рабочего процесса IIS6.0 и отредактируйте его манифест, если он есть, или добавьте новый манифест, если нет (не забудьте проверить, имеет ли он встроенный манифест), чтобы иметь зависимость от MyAssembly.При таком подходе контент манифеста MyAssembly по существу становится частью рабочего контекста для любого кода, работающего внутри IIS6, поэтому это довольно тяжеловесный подход.