Daily Archives: 2008.04.2. 21:52

Kötelező olvasmányok SharePoint fejlesztőknek

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:

 

Advertisements

Open Command Window Here

GUI ide vagy oda, néha bizony szükség van a parancssorra, ráadásul általában egy konkrét mappában szeretnénk dolgozni. A kismillió cd parancs helyett mennyivel praktikusabb lenne, ha a Windows Explorerben bármely mappán jobb egérgombbal kattintva a helyi menüben megjelenne az Open Command Window Here opció.

Ez alapból Vistán sem jelenik meg, de ha nyomva tartjuk a Shift gombot és úgy kattintunk, máris lesz ilyen menüpontunk. Valaki árulja el, hogy kit zavarna, ha mindig ott lenne?!

Windows XP esetén használhatjuk a PowerToysban lévő CmdHere eszközt, ami semmi mást nem csinál, csak beszúrja ez a menüpontot. Ez remek, de nekem ma Windows Server 2003-on elszállt azzal a hibaüzenettel, hogy ő csak az XP-t szereti. Legszívesebben leíratnám a bűnössel százszor, hogy "nem vizsgálok operációs rendszer verziót egyenlőség jellel, hanem mindig a >= jelet használom".

Kénytelen voltam más megoldás után nézni és megalkottam ezt a registry fájlt, ami elvégzi a piszkos munkát:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREClassesFoldershellCommand Prompt]
    @="Megnyitás parancssorban"

    [HKEY_LOCAL_MACHINESOFTWAREClassesFoldershellCommand Promptcommand]
    @="cmd.exe /k pushd %L"

Az importáláshoz admin jog kell (ugyebár ezért nem irogatunk az alkalmazásunkból a HKLM-be), de utána azonnal érvényre jut a változás.

SharePoint fejlesztésnél leggyakrabban a "12 hive"-nak becézett mappára van szükség. Hogy ezt is gyorsan meg tudjam nyitni, létrehoztam a desktopon egy parancsikont, ami ide mutat:

    %windir%system32cmd.exe /k "cd C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12"
 
Technorati Tags: ,,