Eliminar StreamResourceInfo.Stream

Question

Uso StreamResourceInfo.Stream para obtener BitmapImage s de recursos. ¿Es correcto Close y Dispose el flujo después de usarlo? Lo pregunto porque en el generador de perfiles de memoria, me sale un error si lo hago. El generador de perfiles de memoria dice que una instancia eliminada no ha sido codificada.

Si miro en la web, solo puedo encontrar la publicación this sobre este tema. En esta publicación, la persona que responde dice que es malo deshacerse de ella. Sin embargo, si miro las circunstancias y el efecto, no creo que esto sea correcto. ¿Alguien sabe cuál es la acción correcta?
Información adicional: En los ejemplos de msdn que he visto, no eliminan ni cierran.

Editar
Gracias a la respuesta de Rick Sladkeys, he encontrado la solución: asigno StreamResourceInfo.Stream a la StreamSource -property del BitmapImage. En msdn se escribe:

Establezca la propiedad CacheOption en BitmapCacheOption.OnLoad si desea cerrar la secuencia después de crear BitmapImage. La opción de caché OnDemand predeterminada conserva el acceso a la transmisión hasta que se necesite el mapa de bits, y el recolector de basura se encarga de la limpieza.

Esto significa que BitmapImage toma la propiedad de la transmisión. Y es por eso que el generador de perfiles de memoria muestra un error si cierro/elimino la secuencia manualmente: Bitmap mantendrá una referencia a la secuencia (BitmapCacheOption OnDemand) y, por lo tanto, GC no la liberará mientras BitmapImage sea válida, pero la transmisión ya es explícita dispuesto. En este ejemplo específico, deshacerse es una mala idea.
Para la completness, también busqué en msdn el ejemplo del enlace de arriba donde se llamó TextRange.Load. Para Load, es lo opuesto, Load no toma la propiedad y, por lo tanto, el flujo debe cerrarse/desecharse después del acabado.

Answer 1

La confusión, y estoy de acuerdo que es confusa, proviene del concepto sutil pero crítico de la propiedad de la transmisión. En los ejemplos de MSDN, puede verlos como decir "Mire, no Dispose, no Close, ¿entonces se supone que no debo hacer eso?"

Pero la respuesta simple es que alguien tiene que ser responsable de cerrar la secuencia. La API es probable que está llamando:

• Application.GetResourceStream

devuelve un StreamResourceInfo que es un contenedor primitiva de un arroyo y una URL. Claramente, el StreamResourceInfo no posee la transmisión. Entonces, cuando llame al Application.GetResourceStream, usted ahora posee la transmisión que está contenida en ese StreamResourceInfo y, si no hizo nada más con eso, sería responsable de cerrarlo. La API Application transfirió la propiedad de la transmisión a nosotros y la devolvió como un valor para nosotros.

Ahora la parte confusa entra cuando pasa la transmisión a otra entidad.Tomemos un ejemplo de MSDN:

// Navigate to xaml page 
Uri uri = new Uri("/PageResourceFile.xaml", UriKind.Relative); 
StreamResourceInfo info = Application.GetResourceStream(uri); 
System.Windows.Markup.XamlReader reader = new System.Windows.Markup.XamlReader(); 
Page page = (Page)reader.LoadAsync(info.Stream); 
this.pageFrame.Content = page; 

Ahora en este ejemplo no hay ningún Dispose y Close. Pero hay estransferencia de la propiedad de la secuencia de nosotros (la persona que llama) a la instancia XamlReader. La transmisión ya no es nuestra responsabilidad; le pasamos la propiedad a otra persona. De hecho, XamlReader llama al Close cuando termina la transmisión. Un misterio resuelto.

La razón de esto es tan problemático es que el concepto de la propiedad suele ser implícita en la documentación y que se supone que "acaba de entenderlo." Con suerte acaba de volver a visitar º concepto de la propiedad y el hecho de que es transferible, será más fácil para sentirse cómodo no llamando Close con la seguridad de que el nuevo propietario se . E incluso si no lo hacen, ya no es nuestro problema.