Руководство по внедрению расширений In-Process

Расширения внутри процесса загружаются в все процессы, которые активируют их. Например, расширение пространства имен оболочки можно загрузить в любой процесс, который обращается к пространству имен оболочки напрямую или косвенно. Пространство имен оболочки используется многими операциями оболочки, такими как отображение общего диалогового окна файла, запуск документа через связанное приложение или получение значка, используемого для представления файла. Так как расширения внутри процесса могут загружаться в произвольные процессы, необходимо учитывать, что они не негативно влияют на ведущего приложения или другие расширения внутри процесса.

Одна особо примечательная среда выполнения — это CLR , также известная как управляемый код или .NET Framework . Корпорация Майкрософт не рекомендует создавать управляемые расширения в процессе для Windows Explorer или Windows Internet Explorer, так как не рассматривает это как поддерживаемый сценарий.

В этом разделе рассматриваются факторы, которые следует учитывать при определении того, подходит ли любая среда выполнения, кроме среды CLR, подходит для использования расширениями внутри процесса. Примерами других сред выполнения являются Java, Visual Basic, JavaScript/ECMAScript, Delphi и библиотека среды выполнения C/C++. В этом разделе также приводятся некоторые причины, по которым управляемый код не поддерживается в расширениях внутри процесса.

Конфликты версий

Конфликт версий может возникать через среду выполнения, которая не поддерживает загрузку нескольких версий среды выполнения в рамках одного процесса. Версии CLR до версии 4.0 попадают в эту категорию. Если загрузка одной версии среды выполнения исключает загрузку других версий той же среды выполнения, это может создать конфликт, если ведущее приложение или другое расширение внутри процесса использует конфликтующую версию. В случае конфликта версии с другим расширением процесса конфликт может быть трудно воспроизвести, так как сбой требует правильных конфликтующих расширений и режим сбоя зависит от порядка загрузки конфликтующих расширений.

Рассмотрим расширение, выполняемое в процессе, написанное на версии CLR до версии 4.0. Каждое приложение на компьютере, использующее файл Открыть диалоговое окно, может иметь управляемый код диалогового окна и его зависимость CLR, загруженную в процесс приложения. Приложение или расширение, которое первым загружает в процесс приложения версию CLR ниже 4.0, ограничивает, какие версии CLR могут быть использованы этим процессом впоследствии. Если управляемое приложение с диалоговым окном Open построено на конфликтующей версии CLR, расширение может работать неправильно и вызвать сбои в приложении. И наоборот, если расширение загружается первым в процессе, и конфликтующая версия управляемого кода пытается запуститься после этого (например, если управляемое приложение или работающее приложение загружает CLR по запросу), операция завершается ошибкой. Пользователю отображается, что некоторые функции приложения случайно перестают работать, или приложение таинственно завершает работу.

Обратите внимание, что версии СРЕДЫ CLR, равные или более поздней версии 4.0, обычно не подвержены проблеме управления версиями, так как они предназначены для совместного использования друг с другом и с большинством версий среды CLR до 4.0 (за исключением версии 1.0, которая не может сосуществовать с другими версиями). Однако проблемы, отличные от конфликтов версий, могут возникнуть, как описано в оставшейся части этого раздела.

Проблемы с производительностью

Проблемы с производительностью могут возникнуть в средах выполнения, которые вызывают значительное снижение производительности, когда они загружаются в процесс. Штраф производительности может быть в виде использования памяти, использования ЦП, истекшего времени или даже потребления адресного пространства. Среда CLR, JavaScript/ECMAScript и Java, как известно, являются высокопроизводительными средами выполнения. Так как расширения внутри процесса могут быть загружены во многие процессы и часто делаются так в моменты, когда важна производительность (например, при подготовке меню для отображения пользователю), среды выполнения с высокой нагрузкой могут негативно повлиять на общую скорость реагирования.

Среда выполнения с высоким уровнем влияния, потребляющая значительные ресурсы, может привести к сбою в основном процессе или другом расширении в процессе. Например, среда выполнения с высокой нагрузкой, использующая сотни мегабайт адресного пространства для кучи, может привести к тому, что основному приложению не удается загрузить большой набор данных. Кроме того, поскольку расширения внутри процесса могут загружаться в несколько процессов, высокий объем потребления ресурсов в одном расширении может быстро умножаться на высокое потребление ресурсов во всей системе.

Если среда выполнения остается загруженной или в противном случае продолжает использовать ресурсы, даже если расширение, использующее это время выполнения, выгрузило, то эта среда выполнения не подходит для использования в расширении.

Проблемы, связанные с .NET Framework

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

Рентерабельность

Если среда CLR блокирует поток однопотоковой квартиры (STA), например, из-за Monitor.Enter, WaitHandle.WaitOne или оператора блокировки , среда CLR в стандартной конфигурации переходит во вложенный цикл обработки сообщений, пока ждёт. Многие методы расширения запрещены для обработки сообщений, и это непредсказуемое и неожиданное повторное использование может привести к аномальному поведению, которое трудно воспроизвести и диагностировать.

Многопоточность квартиры

Среда CLR создает вызываемые оболочки среды выполнения для объектов объектной модели компонентов (COM). Эти же оболочки вызывателя среды выполнения позже уничтожаются финализатором CLR, который является частью многопоточной модели (MTA). Для перемещения прокси-сервера из STA в MTA требуется маршалинг, но не все интерфейсы, используемые дополнениями, подлежат маршалингу.

Время существования недетерминированных объектов

Среда CLR имеет более слабые гарантии времени существования объекта, чем машинный код. Многие расширения имеют требования к количеству ссылок на объекты и интерфейсы, а модель сборки мусора, используемой средой CLR, не может выполнить эти требования.

• Если объект CLR получает ссылку на COM-объект, ссылка на COM-объект, удерживаемая оболочкой, вызываемой из среды выполнения, не освобождается до тех пор, пока эта оболочка не подвергается сборке мусора. Недетерминированное поведение выпуска может конфликтуть с некоторыми контрактами интерфейса. Например, метод IPersistPropertyBag::Load требует, чтобы объект не сохранял ссылку на контейнер свойств после возврата метода Load.
• Если ссылка на объект CLR возвращается в машинный код, оболочка среды выполнения освобождает свою ссылку на объект CLR при окончательном вызове оболочки среды выполнения к Release, но базовый объект CLR не завершается до тех пор, пока не будет выполнен сбор мусора. Недетерминированное завершение может конфликтовать с некоторыми контрактами интерфейса. Например, обработчики эскизов обязаны немедленно освобождать все ресурсы, когда их счётчик ссылок снижается до нуля.

Допустимое использование управляемого кода и других сред выполнения

Можно использовать управляемый код и другие среды выполнения для реализации расширений вне процесса. Примеры внепроцессных расширений оболочки включают следующее:

• Обработчики предварительного просмотра
• Действия на основе командной строки, такие как регистрируемые под оболочкой\команда\в подключах.
• COM-объекты, реализованные на локальном сервере, для точек расширения Оболочки, которые позволяют активации вне процесса.

Некоторые расширения можно реализовать как встроенные или внепроцессные расширения. Эти расширения можно реализовать как внепроцессные расширения, если они не соответствуют этим требованиям для встроенных расширений. В следующем списке показаны примеры расширений, которые могут быть реализованы как встроенные или внепроцессные расширения:

• IExecuteCommand, связанной с записью DelegateExecute, зарегистрированной в shell\verb\command подразделе.
• IDropTarget, связанный с CLSID, зарегистрированным в интерфейсе оболочки с помощью команды\\DropTarget.
• IExplorerCommandState, связанной с записью CommandStateHandler, зарегистрированной в оболочке\подключом глагола.