SPWeb.Site, ¿debería llamar a Dispose() en él?

Question

Actualizado el 06/08/2009 15:52: Respuesta corta NO. Pregunta original:

No puedo encontrar ninguna referencia que proporcione orientación sobre SPWeb.Site con respecto a la eliminación. He pasado por algunos de los más populares documentación de las mejores prácticas sobre la disposición de objetos de SharePoint:

• http://www.sharepointdevwiki.com/display/public/When+to+Dispose+SharePoint+objects
• http://msdn.microsoft.com/en-us/library/aa973248.aspx
• http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx

Desafortunadamente ninguna de estas directrices mencionar SPWeb.Site. Para dar un poco de contexto, estoy escribiendo una API de extensión público que acepta un SPWeb como un argumento a un método, es decir:

public static void GetWebPartFromCatalog(this SPWeb web, string webPartName) 
{ 
    ...... 

    SPSite site = web.Site; 
    ...... 

    **OR** ?? 

    using (SPSite site = web.Site) 
    { 
     .... 
    } 
} 

He mirado como el método Close() en refelector para SPWeb, que se llama por SPWeb.Dispose() y no hay nada en él que indique que el campo real del miembro de SPSite está dispuesto.

Actualización: 06/08/2009 13:47

En Alex's sugerencia

"Póngalo en un bucle que se ejecuta 100 veces y usar la clave de registro SPRequestStackTrace se describe en Solución de problemas SPSite/SPWeb gotea en WSS v3 y MOSS 2007 para verificar que el código de prueba sea la fuente del problema ".

Me corrió el siguiente fragmento de código incluido dentro de un elemento Web:

for (int i = 0; i < 100; i++) 
{ 
    using (SPWeb web = SPContext.Current.Site.OpenWeb("")) 
    { 
      SPSite site = web.Site; 
      Debug.WriteLine(site.Url); 
    } 
} 

Nada apareció en los registros de SharePoint.

Si bien dudaría en sacar conclusiones reales de este ingenuo experimento, sugeriría que es no necesario para deshacerse de SPWeb.Site. Sería realmente agradable obtener una respuesta concreta de alguien más informado sobre este tema.

Actualización: 06/08/2009 14:52 Impulsado por el comentario de Greg trabajé a cabo las tareas de m_Site y parece que es en última instancia, siempre se pasa a través de los constructores SPWeb internos. P.ej. SPWeb.OpenWeb pasa en este a SPWeb nuevo(). Así que estoy más seguro de que SPWeb.Site debería no eliminarse, de hecho podría causar problemas si fuera así.

Answer 1

Kirk's answer es correcta.Debe tener algún control para un SPSite antes de poder crear un SPWeb, y esa es la misma instancia de SPSite que tendrá cuando llame a SPWeb.Site.

Analicemos las implicaciones de eso: si no controla la creación de SPSite, pero una de sus redes secundarias se entrega desde un código externo, y usted dispone del sitio, cuando se devuelve el control a la llamada código, ¡usted ha eliminado un Sitio que quizás no haya terminado! Ponte en el lugar del código de llamada: pasas un SPWeb a un método, y cuando se hace ese método, el SPSite que estabas usando ha sido cerrado. Siempre es responsabilidad del instalador limpiar los recursos que asignan. No deseche SPSite en este caso.

Answer 2

¿Ha intentado comprobar su montaje con SPDisposeCheck? Tal vez le da un consejo sobre cómo manejar su problema.

Answer 3

Esto no está claro. Hay Stefan's blog que indica ". Debe asegurarse de que solo descarta los objetos SPSite y SPWeb que posee su código". Luego está el this thread de Michael Washam (Microsoft) que establece que este patrón tiene fugas.

A menos que pueda encontrar otra referencia o que alguien más sepa, ¿por qué no la prueba en su servidor de desarrollo y agrega los resultados como respuesta a esta pregunta? Colóquelo en un bucle que se ejecuta 100 veces y use la clave de registro SPRequestStackTrace descrita en Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007 para verificar que el código de prueba sea el origen del problema.

Answer 4

Sólo de pensar en la parte superior de la cabeza (a veces peligroso) ...

Parece que realmente no se puede tener un SPWeb sin tener un SPSite. Por lo tanto, si tiene SPWeb sin pasar por SPSite para obtenerlo (ya sea al hacer un nuevo SPSite o recibir uno), entonces probablemente no tenga que preocuparse por eliminar el SPSite.

Esto es sólo una conjetura, sin embargo. ¡Buena pregunta!

Answer 5

Reflector nos dice que este es el código que se ejecuta dentro del objeto SPWeb cuando se llama a la propiedad del sitio:

public SPSite Site 
{ 
    get 
    { 
     return this.m_Site; 
    } 
} 

No es la creación de un nuevo objeto SPSite, que acaban de volver del que ya tenía, lo que haría estar a la SPWeb.Dispose() para cuidar, si es necesario. Por lo tanto, puede usarlo con seguridad, y evitaría deshacerse de él, no sea que las dependencias de SPWeb se vuelvan inseguras.

Answer 6

A menudo utilizo este patrón en mi código de SharePoint como regla general si llamar a depose no bloquea nada de lo que yo llamo. La otra regla que sigo es intentar no crear extensiones que no causen una ganancia neta en objetos SPRequest (el objeto SPRequest es el objeto .net que habla con todos los objcets de peso pesado)

ahora rompiendo abajo tu ejemplo

for (int i = 0; i < 100; i++) 
{ 
    using (SPWeb web = SPContext.Current.Site.OpenWeb("")) 
    { 
      SPSite site = web.Site; 
      Debug.WriteLine(site.Url); 
    } 
} 

la clave aquí es la SPContext.Current.Site el SPContext va a limpiar después de que sea auto correctamente (uno de los pocos objetos que lo hace) ya que sabemos que el sitio se limpia correctamente espero que las bandas se llevó limpiado, sin embargo, esto está lejos de ser la respuesta correcta a tu pregunta. (Tenga en cuenta que debe tener fugas de las bandas que tienes a través de OpenWeb)

public static void GetWebPartFromCatalog(this SPWeb web, string webPartName) 

que necesita para obtener la SPSite que hacer algo con las piezas de la tela.

1. la propiedad web.Site de hecho limpia después de sí mismo si la web está dispuesta.
2. ¿Por qué no pasar el objeto SPSite y dejar que el usuario de la función se preocupe por ello? En la mayoría de los casos, creo que llamarían usando SPContext.Current.Site de todos modos.
3. mayoría de las veces tengo que preocuparse acerca de los permisos, no todo el mundo de nuestros dlls terminan en la GAC ​​así que cuando escribo un nuevo método de extensión termino tener que envoltorio que un SPSecurity.CodeToRunElevated

con los de importa que terminaría escribiendo esto como. . . Ahora Desechar el cheque se apagará en este caso porque la SPSite el que se pasa como argumento porque no puede rastrear en qué ámbito se dispone en.

public static void GetWebPartFromCatalog(this SPSite site, string webPartName) { 
    SPSecurity.CodeToRunElevated(() => { 
     using(SPSite suSite = new SPSite(site.Id)){ 
      //do what you need to do 
     } 
    }; 
} 

Answer 7

Stefan Gobner tiene un excelente artículo sobre esto: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

... Y asegúrese de utilizar el SPDispose check tool en su código base.

Answer 8

es necesario eliminar la instancia SPSite/SPWeb si se trata de un objeto nuevo

por ejemplo

using(SPSite site = new SPSite("url")) 
{ 
    DoSomething; 
} 

aquí usando se encargará de eliminar el objeto sin embargo, si usted tiene la referencia del objeto de SPContext.Current no debe explicitar el objeto ya que la referencia debería estar disponible desde SPContext.Current.