.net - manager - Ámbito del contendor invocable en tiempo de ejecución(RCW): ¿dominio de proceso o aplicación?
instalar google tag manager (3)
En managed, tenemos una asignación de memoria caché de dominio por aplicación canónica IUnknowns de nuevo a RCW. Cuando un IUnknown ingresa al sistema (a través de una llamada Marshal, a través de la activación, como un parámetro de retorno de una llamada a un método, etc.), verificamos la caché para ver si ya existe un RCW 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 caché.
¿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 de la cantidad de referencias que existan 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 utilizo Marshal.ReleaseComObject (x) en un bucle hasta que su cuenta 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 documento oficial de MSDN dice por proceso (para la versión 2.0+), pero le falta esta frase para ver. 1.1 del doc .
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 envié un correo electrónico solicitando una aclaración, pero si alguien más tiene que agregar algo, hágalo.
Gracias
De acuerdo con los mismos documentos:
El tiempo de ejecución mantiene un único RCW por proceso para cada objeto.
Creo que podemos suponer con seguridad que object = instance , por lo que si addins / AppDomains no contiene referencias a la misma instancia, la llamada a ReleaseComObject no liberará las 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í, 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 invocado en su AppDomain no hará que los RCW en otros AppDomains pierdan la referencia a esa instancia.
El artículo del blog de Mason Bendixen que Ilya cita es el correcto: el RCW tiene un alcance para el Dominio de aplicación, no para el proceso. Solo puedo adivinar que el artículo de Runtime Callable Wrapper (MSDN 2.0) hablaba "casualmente". Ese artículo no es necesariamente incorrecto en el sentido general, porque es más típico ejecutarlo usando un solo dominio de aplicación, pero esa frase no es técnicamente precisa.
En cuanto a su pregunta específica:
"Me gustaría saber qué sucede si uso Marshal.ReleaseComObject (x) en un bucle hasta que su 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)? ? "
La respuesta a esto 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 Asistente COM Shim versión 2.3.1 que puede usar para aislar su complemento. La documentación para el Asistente COM Shim se puede encontrar aquí: Aislar extensiones de Microsoft Office con el Asistente COM Shim versión 2.3.1 .
El asistente COM Shim Wizard utiliza la reflexión para crear 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 y por separado, su complemento se identifica correctamente por separado por Microsoft Office de todos los demás 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 aplicación separado, los envoltorios de rmadores 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 (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 Asistente de COM Shim es que al operar fuera de un Dominio de Aplicación 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. (Por cierto, tengo curiosidad por saber cómo lo está haciendo ... ¿Está creando explícitamente su propio AppDomain? La plantilla de complemento predeterminada en Visual Studio no se ejecuta en un Dominio de aplicaciones separado y se carga utilizando mscoree.dll.)
Si está creando su propio dominio de aplicación, su código está aislado, pero su identidad puede no estar separada de otros complementos, ya que su complemento aún estaría compartiendo el cargador mscoree.dll predeterminado, a menos que utilice otros medios para abordar esto.
Espero que esto ayude...