Cuándo utilizar ReleaseComObject vs FinalReleaseComObject?

Question

¿Cuándo debo usar Marshal.FinalReleaseComObject contra Marshal.ReleaseComObject?

¿Existe algún peligro al usar Marshal.FinalReleaseComObject?

Answer 1

Hay alguna virtud en FinalReleaseComObject, se bloqueará su programa más rápido. "El objeto COM que se ha separado de su RCW subyacente no se puede usar", es el CLR que le informa que usted se encarga de los recuentos de referencias COM usted mismo en lugar de dejarlo, el CLR fue un error. Su millaje puede variar, realmente no puede confiar para hacerlo bien cuando funciona en su máquina de desarrollo. Asegúrese de implementar buenos informes de errores cuando implemente el código en la máquina de su cliente.

La virtud es que hay un solo lugar en su código donde lo obtuvo mal, la llamada FinalReleaseComObject. Se pone mucho más borroso cuando usas ReleaseComObject. Porque eso pasará desapercibido por un tiempo, bloqueando su programa cuando el CLR llame al IUnknown::Release() final, el que destruye el objeto. Muy lejos de una llamada incorrecta ReleaseComObject. Pero ese es el escenario del día del juicio final, el resultado más probable es que la llamada simplemente no haga ninguna diferencia porque te perdiste los duros. Como mumble["foo"], una referencia del indexador que es muy difícil de ver.

Bueno, mi consejo es obvio: no hagas esto. Usted está compitiendo con una máquina que nunca se equivoca. Simplemente es un poco lento al hacerlo. Un muy buen "informe de la vida real" es available here. La sección de "asesino silencioso" es muy relevante.

Si es absolutamente imprescindible que un servidor COM salga instantáneamente, deje que la máquina se encargue de obtener todos los recuentos de referencia en 0. Lo hace con GC.Collect(). Pero tenga en cuenta que debe realizar esa llamada correctamente si desea que esto también funcione cuando depure. No funcionará en el mismo método que usa los objetos COM, explicado en this answer. Ponlo en el método de llamada en su lugar.