Ámbito de envoltura invocable en tiempo de ejecución (RCW): ¿dominio de proceso o aplicación?

Question

¿Cuál es el alcance de Runtime Callable Wrapper (RCW) cuando se hace referencia a objetos COM no administrados? De acuerdo con los documentos:

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

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

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

EDITAR: Perfecto - ahora la confusión es aún mayor. En base a las 2 respuestas (de Lette e Ilya) tenemos 2 respuestas diferentes. El MSDN doc oficial dice por proceso (para la versión 2.0+), pero le falta esta frase para ver. 1.1 of the doc.

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

Como su artículo es viejo (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 logrado, tenemos una aplicación por dominio caché de mapeo IUnknowns canónicas de nuevo a la MRF. Cuando un IUnknown entra en el sistema (a través de una llamada Mariscal, través de la activación, como un parámetro de retorno de una llamada de método, etc.), , comprobamos la memoria caché para ver si un RCW ya existe para el objeto COM. Si existe una asignación, se devuelve una referencia al RCW existente. De lo contrario, se crea un nuevo RCW y se agrega una asignación de memoria caché .

de Mason's Blog

Answer 2

acuerdo con el mismo docs:

El tiempo de ejecución mantiene una única RCW por proceso para cada objeto.

creo que podemos asumir con seguridad que objeto = instancia, por lo que si los AddIns/dominios de aplicación no se sostiene referencias a la misma instancia, la llamada a ReleaseComObject no va a liberar las referencias a instancias creadas en otros lugares .

Editar: La redacción de los documentos puede ser incorrecta, as stated elsewhere. Si es así, dado que su complemento se está ejecutando en un dominio de aplicación diferente, tiene suerte. Incluso si los diferentes complementos hacen referencia a la misma instancia (por ejemplo, un objeto Message en Outlook), ReleaseComObject llamado en su AppDomain no provocará que los RCW en otros AppDomains pierdan la referencia a esa instancia.

Answer 3

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

cuanto a su pregunta específica:.

"Me gustaría saber qué sucede si utilizo Marshal.ReleaseComObject (x) en un bucle hasta que sea cuenta llegue a 0 (como se recomienda ) Will libera referencias de otros complementos (ejecutándose en otro dominio de aplicación en el mismo proceso de Outlook) ?? "

La respuesta depende de cómo configure su complemento. En general, si no toma precauciones, la respuesta es sí, afectaría las referencias en otros complementos que operan desde dentro del mismo dominio de aplicación. Pero como dice que se está ejecutando desde un Dominio de aplicación diferente, entonces, no, no sería así.

Hay un COM Shim Wizard Version 2.3.1 que puede utilizar para aislar su complemento. La documentación para el Asistente COM Shim se puede encontrar aquí: Isolating Microsoft Office Extensions with the COM Shim Wizard Version 2.3.1.

El asistente COM Shim Wizard utiliza la reflexión para generar un cargador de interfaz de usuario COM personalizado que carga su ensamblaje de complemento dentro de un dominio de aplicación separado. Esto crea seguridad en dos aspectos:

(1) Al usar un punto de entrada COM personalizado e independiente, su complemento se identifica correctamente por separado por Microsoft Office del resto de complementos. De lo contrario, de manera predeterminada, todos los complementos comparten el mismo cargador predeterminado de mscoree.dll. El problema con compartir el mismo cargador es que si cualquier complemento tiene un bloqueo, entonces Microsoft Office identificará a mscoree.dll como el origen 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 aplicaciones separado, los envoltorios de rmadores en tiempo de ejecución (RCW) están aislados de los otros complementos que se cargan en el mismo proceso. En este caso, si llama a Marshal.ReleaseComObject (object) o Marshal.FinalReleaseComObject (object), entonces no afectará a los complementos de nadie más. Lo que es más importante, si alguno de esos complementos realiza esas llamadas, su complemento estaría protegido contra daños. :-)

La desventaja de usar el COM Shim Wizard es que al operar fuera de un AppDomain separado hay una sobrecarga de clasificación adicional. No creo que esto deba ser notable para un complemento de Microsoft Outlook. Puede ser un factor, sin embargo, 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 indicó que ya está ejecutando su complemento desde un dominio de aplicación diferente. Si esto es cierto, entonces ya está aislado de Marshal.ReleaseComObject (objeto) y Marshal.FinalReleaseComObject (objeto) llama con respecto a otros AppDomains. (Tengo curiosidad por saber cómo lo está haciendo, por cierto ... ¿Está creando explícitamente su propio AppDomain? La plantilla de complemento predeterminada en Visual Studio hace que no se ejecute en en un Dominio de aplicaciones separado y cargue con 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 Usaste otros medios para solucionar esto.

espero que esto ayude ...