Вопрос по interop, com, .net, appdomain, marshalling – Область действия вызываемой оболочки во время выполнения (RCW) - область процесса или приложения?

6

Какова область действия Runtime Callable Wrapper (RCW) при обращении к неуправляемым COM-объектам? Согласно документам:

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

Если бы мне пришлось «угадать» - это объяснение должно означать «по одному на процесс», но так ли это на самом деле? Любая дополнительная документация будет очень приветствоваться.

Мое приложение работает в своем собственном домене приложений (это надстройка для Outlook), и я хотел бы знать, что произойдет, если я использую Marshal.ReleaseComObject (x) в цикле, пока его счетчик не достигнет 0 (как рекомендуется). Выпустит ли он ссылки из других надстроек (работающих в другом домене приложения в том же процессе Outlook)?

РЕДАКТИРОВАТЬ: Отлично - теперь путаница еще больше. На основе 2 ответов (от Lette и Ilya) у нас есть 2 разных ответа. ОфициальныйДокумент MSDN говорит за процесс (для версии 2.0+), но отсутствует это предложение дляверы. 1.1 документа.

В то же время, в статье Мейсона Бендиксена говорится, что это на домен приложения.

Поскольку его статья старая (апрель 2007 г.), я отправил ему электронное письмо с просьбой дать разъяснения, но если кто-то должен что-то добавить, сделайте это.

Спасибо

Ваш Ответ

3   ответа
3

на которую ссылается Илья, правильна: RCW относится к домену приложений, а не к процессу. Я могу только догадываться, чтоCallable Wrapper во время выполнения (MSDN 2.0) статья говорила "случайно". Эта статья не обязательно неверна в общем смысле, потому что ее наиболее типично выполнить с использованием только одного домена приложений, но это предложение не является технически точным.

Что касается вашего конкретного вопроса:

«Я хотел бы знать, что произойдет, если я использую Marshal.ReleaseComObject (x) в цикле, пока его счетчик не достигнет 0 (как рекомендуется). Будет ли он освобождать ссылки от других надстроек (работающих в другом домене приложения в том же процессе Outlook)? ?»

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

СуществуетCOM Shim Wizard версия 2.3.1 что вы можете использовать для изоляции вашей надстройки. Документацию по мастеру COM Shim можно найти здесь:Изоляция расширений Microsoft Office с помощью мастера Shim COM версии 2.3.1.

Мастер COM Shim Wizard использует отражение для создания настроенного фронтального загрузчика COM, который загружает сборку надстройки в отдельный домен приложения. Это создает безопасность в двух отношениях:

(1) Используя отдельную настроенную точку входа COM, Microsoft Office правильно идентифицирует вашу надстройку отдельно от всех других надстроек. В противном случае по умолчанию все надстройки имеют общий загрузчик mscoree.dll по умолчанию. Проблема с совместным использованием одного и того же загрузчика заключается в том, что в случае сбоя какой-либо надстройки Microsoft Office определит mscoree.dll как источник проблемы и не загрузит ее автоматически в следующий раз. Вы можете включить его снова вручную, но ваша надстройка не загрузится автоматически в следующий раз из-за проблемы в чужой надстройке!

(2) Загружая вашу сборку в отдельный домен AppDomain, вызываемые оболочки времени выполнения (RCW) изолируются от других надстроек, загружаемых в тот же процесс. В этом случае, если вы вызовете Marshal.ReleaseComObject (object) или Marshal.FinalReleaseComObject (object), вы не будете влиять на чужие надстройки. Что еще более важно, если какие-либо другие надстройки совершают такие вызовы, ваша надстройка будет защищена от повреждения. :-)

Недостатком использования COM Shim Wizard является то, что при работе с отдельным доменом приложений возникают дополнительные издержки на сортировку. Я не верю, что это должно быть заметно для надстройки Microsoft Outlook. Однако это может быть важным фактором для некоторых интенсивных подпрограмм, которые имеют много вызовов объектной модели, например иногда для надстройки Microsoft Excel.

Вы заявили, что уже запускаете надстройку из отдельного домена приложений. Если это так, то вы уже изолированы от вызовов Marshal.ReleaseComObject (объект) и Marshal.FinalReleaseComObject (объект) относительно других доменов приложений. (Кстати, мне интересно, как вы это делаете ... Вы явно создаете свой собственный домен приложений? Шаблон надстройки по умолчанию в Visual Studioне запускается в отдельном домене приложений и загружается с помощью mscoree.dll.)

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

Надеюсь, это поможет...

Для этого я бы прочитал ссылку, которую я разместил выше, на статью «Изоляция расширений Microsoft Office с помощью COM Shim Wizard версии 2.3.1», найденную наmsdn.microsoft.com/en-us/library/bb508939.aspxособенно раздел под названием «Как работает COM Shim». Mike Rosenblum
Спасибо за ответ. Я использую шим-решение. Но я все еще запутался из-за термина «процесс» в документации RCW (версия 2.0 и выше). И процесс не является доменом приложения. Sunny Milenov
Можете ли вы предоставить документ, который подтверждает ваше (2) утверждение: «Загружая вашу сборку в отдельный домен приложений, вызываемые оболочки времени выполнения (RCW) изолируются от других надстроек, загружаемых в тот же процесс». Sunny Milenov
1

Среда выполнения поддерживает один RCWза процесс для каждого объекта.

Я думаю, что мы можем с уверенностью предположить, чтообъект = экземпляр, так что если addins / AppDomains не содержит ссылок на один и тот же экземпляр, вызовReleaseComObject не будет выпускать ссылки на экземпляры, созданные в другом месте.

Изменить: формулировка документов может быть неправильным,как указано в другом месте, Если так, то ваша надстройка работает в отдельном домене приложений, вам повезло. Даже если разные надстройки ссылаются на один и тот же экземпляр (например, объект сообщения в Outlook),ReleaseComObject вызов в вашем домене приложений не приведет к тому, что RCW в других доменах приложений потеряют ссылку на этот экземпляр.

Мейсон может быть верным на момент написания статьи, так как документы 1.1 не говорят «процесс», а документы 2.0 и более поздних платформ говорят «за процесс», а не за домен приложения. Sunny Milenov
Объект сообщения, предоставляемый Outlook, вероятно, является общим - один экземпляр. Однако каждый AppDomain имеет свой собственный указатель (RCW) на этот экземпляр и поддерживает свой собственный внутренний счетчик ссылок (если Мейсон прав, и я верю, что он есть). Christoffer Lette
Если мы сделаем это предположение, то встанет вопрос об определении «экземпляра» - т.е. допустим, что каждое сообщение является объектом - означает ли это, что каждое добавление создает / использует разные COM (экземпляр) для доступа к сообщению, или существует один единственный COM-объект (экземпляр) и все к нему обращаются? Sunny Milenov
3

каждого приложения обратно в RCW. Когда IUnknown входит в систему (через вызов маршала, через активацию в качестве параметра возврата из вызова метода и т. Д.), Мы проверяем кэш, чтобы увидеть, существует ли уже RCW для COM-объекта. Если сопоставление существует, возвращается ссылка на существующее RCW. В противном случае создается новый RCW и добавляется сопоставление кеша.

изБлог Мейсона

Похожие вопросы