¿Alcance envolvente exigible en tiempo de ejecución (RCW): proceso o dominio de aplicación?

Question

¿Cuál es el alcance de Runtime Callable Wrapper (RCW), cuando se hace referencia a objetos COM no administrados? Según los documentos:

  

El tiempo de ejecución crea exactamente un RCW   para cada objeto COM, independientemente de la   número de referencias que existen en   ese objeto.

Si tuviera que " adivinar " - esta explicación debería significar " una por proceso " ;, pero ¿es realmente? Cualquier documentación adicional será muy bienvenida.

Mi aplicación se ejecuta en su propio dominio de aplicación (es un complemento de Outlook), y me gustaría saber qué sucede si uso Marshal.ReleaseComObject (x) en un bucle hasta que la cuenta llegue a 0 (como se recomienda). ¿Publicará referencias de otros complementos (que se ejecutan en otro dominio de aplicación en el mismo proceso de Outlook)?

EDIT: Perfecto - ahora la confusión es aún mayor. Basado en las 2 respuestas (de Lette e Ilya) tenemos 2 respuestas diferentes. El MSDN doc oficial dice por proceso (para ver. 2.0+), pero falta esta oración para ver. 1.1 del documento .

Al mismo tiempo, en el artículo de Mason Bendixen, dice que es por dominio de aplicación.

Como su artículo es antiguo (abril de 2007), le he enviado un correo electrónico solicitando una aclaración, pero si alguien más tiene que agregar algo, hágalo.

Gracias

Answer 1

  

En administrado, tenemos un dominio por aplicación   cache   mapeo de IUnknowns canónicos de nuevo a   RCWs. Cuando un IUnknown entra en el   sistema (a través de una llamada de mariscal,   A través de la activación, como retorno.   parámetro de una llamada de método, etc.),   Verificamos el caché para ver si hay un RCW.   Ya existe para el objeto COM. Si   existe un mapeo, una referencia a la   RCW existente se devuelve. De lo contrario un   Se crea nuevo RCW y una asignación de caché   se ha añadido.

de Blog de Mason's

Answer 2

El artículo del blog de Mason Bendixen que Ilya cita es correcto: el RCW tiene el alcance del dominio de aplicación, no del proceso. Solo puedo adivinar que el Runtime Callable Wrapper (MSDN 2.0) el artículo estaba hablando " casualmente " ;. Ese artículo no es necesariamente incorrecto en el sentido general, porque es más típico ejecutarlo usando solo un dominio de aplicación, pero esa oración no es técnicamente precisa.

En cuanto a su pregunta específica:

  

" Me gustaría saber qué sucede si   usar Marshal.ReleaseComObject (x) en un   bucle hasta que su cuenta llega a 0 (como   recomendado). Será liberado   referencias de otros complementos   (ejecutándose en otro dominio de aplicación   en el mismo proceso de Outlook)? "

La respuesta a esto depende de cómo configure su complemento. En general, si no toma precauciones, entonces la respuesta es sí, afectaría las referencias en otros complementos que operan desde el mismo dominio de aplicación. Pero dado que declara que está ejecutando desde un dominio de aplicación separado, entonces, no, no lo haría.

Hay un COM Shim La versión 2.3.1 del asistente que puede usar para aislar su complemento. La documentación del COM Shim Wizard se puede encontrar aquí: Aislando las Extensiones de Microsoft Office con el COM Shim Wizard versión 2.3.1 .

El COM Shim Wizard utiliza la reflexión para crear un cargador frontal personalizado COM que carga su conjunto de complementos dentro de un dominio de aplicación separado. Esto crea seguridad en dos aspectos:

(1) Al usar un punto de entrada de COM personalizado y separado, su complemento está correctamente identificado por separado por Microsoft Office de todos los demás complementos. De lo contrario, de forma predeterminada, todos los complementos comparten el mismo cargador mscoree.dll predeterminado. El problema de compartir el mismo cargador es que si cualquier complemento tiene un bloqueo, entonces Microsoft Office identificará a mscoree.dll como la fuente del problema y no lo cargará automáticamente la próxima vez. Puede volver a activarlo manualmente, pero su complemento no se cargará automáticamente la próxima vez debido a un problema en el complemento de otra persona.

(2) Al cargar su ensamblaje dentro de un dominio de aplicación separado, las envolturas con cierre de tiempo de ejecución (RCW) se aíslan de los otros complementos que se cargan en el mismo proceso. En este caso, si llama a Marshal.ReleaseComObject (objeto) o Marshal.FinalReleaseComObject (objeto), no estará afectando a los complementos de nadie. Y lo que es más importante, si alguno de esos otros complementos realiza tales llamadas, su complemento estará protegido contra la corrupción. :-)

La desventaja de usar el Com Shim Wizard es que, al operar desde un dominio de aplicación separado, hay una sobrecarga adicional de clasificación. No creo que esto deba ser notable para un complemento de Microsoft Outlook. Sin embargo, puede ser un factor para algunas rutinas intensivas que tienen muchas llamadas al modelo de objetos, como a veces puede ser el caso de un complemento de Microsoft Excel.

Usted declaró que ya está ejecutando su complemento desde un dominio de aplicación separado. Si esto es cierto, entonces ya está aislado de las llamadas Marshal.ReleaseComObject (objeto) y Marshal.FinalReleaseComObject (objeto) con respecto a otros AppDomains. (Tengo curiosidad por saber cómo lo está haciendo, por cierto ... ¿Está creando explícitamente su propio dominio de aplicación? La plantilla de complemento predeterminada en Visual Studio no se ejecuta no en un dominio de aplicación separado y se carga utilizando el mscoree.dll.)

Si está creando su propio dominio de aplicación, su código está aislado, pero su identidad podría no estar separada de otros complementos, sin embargo, ya que su complemento aún estaría compartiendo el cargador mscoree.dll predeterminado, a menos que lo haya utilizado algunos otros medios para abordar esto.

Espero que esto ayude ...

Answer 3

Según los mismos documentos:

  

El tiempo de ejecución mantiene un solo RCW por proceso para cada objeto.

Creo que podemos asumir con seguridad que object = instance , por lo que si los complementos / AppDomains no contienen referencias a la misma instancia, la llamada a ReleaseComObject no publicará referencias a instancias creadas en otro lugar.

Editar: la redacción de los documentos puede ser incorrecta, como se indica en otra parte . Si es así, ya que tu complemento se está ejecutando en un dominio de aplicación separado, estás de suerte. Incluso si los diferentes complementos hacen referencia a la misma instancia (por ejemplo, un objeto de mensaje en Outlook), ReleaseComObject al que se llama en su dominio de aplicación no hará que los RCW en otros dominios de aplicación pierdan la referencia a esa instancia.