Amikor egy konferencián vagy cikkben kódrészlet kerül elő, gyakran nem az a lényeg, hogy az minden szempontból korrekt legyen, hanem hogy bemutassa valaminek a megvalósítását. Az érthetőség kedvéért ilyenkor el szoktuk hagyni a hibakezelést, a naplózást, a memóriakezelést. Sajnos néha ezek a kóddarabkák egy az egyben éles projektek részei lesznek...
SharePoint proramozás esetén a példákban szinte mindig elmarad az IDisposable interfész kezelése, pedig ez nagyon fontos. A gyakorlatban olyan hibákat tud okozni, amit szinte lehetetlen kidebuggolni. Ismerjük már a nagyon sokat mondó Unexpected error üzenetet? Na most képzeljük el azt a köbön. A jelenség az, hogy míg a kód tökéletesen fut a fejlesztői gépen, sőt az éles szerveren is, nagy terhelés esetén az egész szerver elkezd megbízhatatlanná válni, nem jelennek meg oldalak, megsokasodnak a timeoutok és váratlanul újraindul az IIS AppPool.
Egy percig sem szabad megfeledkeznünk arról, hogy bár .NET-ben programozzuk a SharePoint objektum modelljét, valahol a mélyben natív kód lakozik, aminek igenis szüksége van a memória menedzsmentre. Nem csak a GC-re, hanem a mi segítségünkre is. Tehát igenis használnunk kell a Dispose metódust! A dologban az a nehéz, hogy viszont vannak esetek, amikor nem szabad meghívni a Dispose-t!
Pontatlanul, de röviden fogalmazva: ha SPContext vagy SPControl osztálytól kapunk SPSite vagy SPWeb objektumot, akkor nem kell rajta Dispose-t hívni, ha valamely más osztály tulajdonságán, gyűjteményén vagy konstruktorán keresztül, akkor általában kell. További nehézség, hogy más tulajdonságok elérésekor is keletkezhetnek megsemmisítendő objektumok, például egy SPSite.Owner lekérdezése után az SPSite.RootWeb objektumra kell Dispose-t hívni, még ha nem is használtuk.
Mások szerencsére már összeírták ezeket az okosságokat és mivel a WSS objektum modell programozásának ez az alfája, ezért minden SharePoint fejlesztő számára kötelező olvasmányok az alábbi cikkek: