Iga lahendus tekitab uusi probleeme ehk alati võib leida veel ühe bugi.

Silverlight 1.1 on nüüd Silverlight 2.0

Mõned tunnid tagasi sai avalikuks uudis Silverlight 1.1 ümbernimetamisest Silverlight 2.0 -ks. Ümbernimetuse põhjuseks on järgmise release funktsionaalsuste suurus ja maht ning on suuruselt pigem uue versiooni välja laskmine, kui mõned lisafunktsionaalsused olemasolevale platvormile (release -le). Ka avalikustati informatsiooni hetke seisu kohta ning plaanid tulevikku.

Viited on siin:

• Tim Sneath
• Scott Guthrie (laiemalt .Net -i veebi platvormide arengust - .Net 3.5 extensions, Silverlight, IIS 7)

TFS 2008 installeerimine

Nädalavahetus sai tegeletud VSTS2008 ülesseadmsiega ja seal hulgas ka TFS2008 -ga. Mõtlesin, et jagaks installeerimiskogemust TFS2008 osas.

Kõige üldisemalt võiks öelda, et kogemus oli positiivne - installeerimine on mugav ning parima toimimise saavutamiseks tehakse piisavalt süsteemi konfiguratsiooni kontrollimisi. Muidugi pidin ma oma elu põnevaks tegema ning väikese seikluse lisaks tekitama. Aga alustaks sellest, et näitan lugejale põhiakent ning tutvustan TFS2008 installeerimise konseptsiooni.

Kasutajaliides, nagu te näete on ilus. Setup -ga avanevas aknas on kohe viited juhenditele ning võimalik käivitada erinevaid installisatsioone. TFS 2008 puhul on viis komponenti, mida installeerida:

• TFS
  • Koodihaldus
  • Issue/Bug tracking
  • Raportid (SQL Reporting Services)
  • Meeskonna lehekülg koos WSS -ga
  • Analüüsiteenused
• TFS Proxy
  • Vaheserver, kui tegu on suure ja hajutatud arenduskeskkonnaga, siis see on nagu cache vahepeal.
• TFS Build
  • Continuous Integration - Build server
• Team Explorer
  • Kliendi vahendid, et hallata TFS serveris TFS -i keskkonda
• WSS Extensions
  • Installeeritakse koos TFS -ga soovi korral
  • Võimalik installeerida olemasolevale Sharepoindile

TÄHTIS !!! Kindlasti installeerige eel-nõutud (pre-requisite) tarkvara täpselt juhendi järgi!!

Kusjuures peamiselt on eelnevalt  vaja SQL Server 2005 -te koos Reporting ja Analytics teenustega. Ja SQL Server 2005 -e instaleerimisest kooruski välja minu seiklus :)

Seiklus

Hajameelsusest või mõnest muust kiiksust ajendatuna määrasin ma SQL Server 2005 -e collationiks Estonian....CS_AS (eesti collationi). Peale SQL Server 2005 -e installeerimist hakkan installeerima TFS2008 -te. Iga TFS -i komponendi (üleval kirjutatud loetelu) installimisel tehakse põhjalik kontroll (System Health Check), et kõik eel-nõutud tarkvara oleks korrektselt installeeritud ja seadistatud ning TFS -i installisatsiooni oleks edukas (ja et poleks üllatusi hiljem). Igatahes sain mina TFS -i kontrolli tulemuseks järgmise vaate:

Täheldage, et NEXT ei saa vajutada. Minnes detailidele saab väga spetsiifilise info vea kohta (soovitan klikata pildile, avaneb uues aknas ja suuremalt - mugavam lugeda).

Ja olingi pähkli otsas - vale collation instantsil - ei saa TFS -i peale panna. Sellest koorus välja üks mu varajasem postitus SQL Server 2005 -e instantsi collationi vahetamise kohta.

Igatahes, collationiks peaks olema (NIMI)_CI_AS ja NON binary. Sobib ka default, milleks minu teada on SQL_Latin1_General_CP1_CI_AS.

Õppetund, järgige juhendeid korrektselt ning collationiga mängige juhendis kirjeldatud reegleid järgides. Kui te teete nii, siis saate vajutada next ja näete hoopis all asuvat pilti.

Nii pisikene see seiklus oligi. Räägin TFS -i kasutamisest ja uutest lemmik omadustest mõni postitus hiljem.

Rohkem lugemist uues Team Foundation -i kohta on siin.

Sharepointi IIS -i application pool -i konfigureerimine

Ma ei ole küll administraator, aga .Net -i veebirakenduste arendamisel olen ma tihti kokku puutunud ka rakenduserveris application pool -i ja veebi saidi konfigureerimisega (tihti see jääbki arendajate teha). Siin on näide headest seadetest Sharepointi paiknemisel IIS 6.0 -s. Kindlasti saab loogiliselt antud andmete põhjal arvestada ka seadeid teiste rakenduste jooksutamiseks IIS -s (Internet Information Services). 

Application pool

IIS -s on iga veebirakendus, seotud application pool -iga, mis määrab ära jooksutava protsessi konfiguratsiooni, jooksutaja konto (ja sellest tulenevalt ka õigused) ning muud konfiguratsiooni seadmed nagu web garden (mitu jooksutaja protsessi samade seadetega).

Hea tava on siduda üks rakendus, ühe application pool -iga, et isoleerida kaks lahendust teineteisest. See võimaldab näiteks veebi rakenduse ressursside vabastamist, ilma teist rakendust mõjutamata. ASP.NET -i lahenduste juures võib see tähtsaks osutuda, kuna algse kompileerimise ning tulemuse cache -i panemise poolt tekitatav jõudluslöök (performance hit) on tavaliselt piisavalt suur, et seda regulaarselt korrata ei soovita (eriti kui põhjus tuleneb muust rakendusest). Samas vast kõige tähtsam siinjuures on rääkida turvalisususest - kui teil on mitu veebirakendust, mis on seotud sama application pooliga (samas tööprotsess), siis on täiesti reaalne võimalus/oht, et ühest rakendusest saab ligi teisele rakendusele selle protsessi piires (neil on ühine app_domain). Puhtalt selleks, et tagada turvalisust (isoleerimisega) tuleks igale veebirakendusele luua oma application pool.

Sharepointi veebi saidi application pool -i seaded

Esmalt - ei ole sharepointi serveril mis jookustab IIS -i soovituslik liigseid veebirakendusi ning application poole luua. Sharepoint -i veebirakendus on tavaliselt ise piisavalt suur funktsionaalsuse poolest. Soovituslik on omada ühte application pool -i Administreerimisliidese jaoks ning teist veebirakenduse jaoks. Ühes serveris mitte rohkem kui 3-4 application pooli (oleneb ressurssidest, veebirakenduste arvust, turvalisuse seadetest, mitte funktsionaalsetest nõuetest nagu kasutajate koormus lahendusel jne). Mina räägin hetkel lahendusest, kus ühes IIS -s jookseb 1 Sharepointi admin liides ja 1 sharepointi veebirakendus (tegu on n-ö dedicated live keskkonnaga).

Kui valite Properties Sharepointi veebi rakenduse application  pooli peal, siis avaneb järgnev aken (kuid seaded ei ole samad, nagu siin - veel). Recycling tab -i all määratakse ära kui palju ressursse üks tööprotsess saab ning millal selle tööprotsessi ressursse kindlasti vabastatakse. Teil on võimalik vabastamiseks määrata kindlad kellaajad.
Mina pööraks tähelepanu maksimaalse füüsilise ja virtuaalse mälu kasutusele võtu piiramiseks. Soovituslik on seada see 800 MB juurde (IIS -i protsess, mis on suurem kui 1GB võib tekitada probleeme ja ei tasu nii suureks lasta - samas liiga väike füüsilise mälu mahu piirang tähendab, et swapitakse palju). See on maksimaalne mälukasutus - tööprotsess seda vaikimisi ära ei hõiva.

Järgmisel tabiks on Performance. Siin all on mõistlik piirata maksimaalse päringute arv ning kas jooksutatakse antud seadetega üks tööprotsess või mitu. Mitme tööprotsessi jooksutamise pluss on see, et päringuid teenindab kaks või enam protsessi ja kui ühe protsessiga toimub näiteks ressursside vabastus (vms), siis teine saab edasi edukalt toimida. Negatiivne on kindlasti see, et kui ühe protsessi maksimaalme mälu kasutus on 800 MB, siis kahe protsessi oma on 1,6GB. Sharepointi raames on soovituslik ühe rakenduse piires jooksutada 2-3 samaaegset (kindlasti on piiranguks ressursid ja mina olen valinud kaks antud juhul).

Viimaseks tab -ks, mida seadistada on Health. Antud sektsioonis olen piiranud tööprotsessi pingimise sagedust - default on 30 sekundit, aga mulle on tundunud, et 60 on piisav sagedus. Kindlasti keerake maha rapid-fail protection. Kui peaks juhtuma, et disabletakse teie application pool, siis sharepointi saiti enam kasutada ei ole võimalik (administraator peab minema ja käsitsi käivitama uuesti). See on kasulik, kui teil on veebifarm (palju veebi servereid) ja kui üks neist pikali on ning ei vasta, siis teised ju ikka töötavad.

Viimasel tabil on tegelikult ka määratud jooksutaja konto, minu soovitus on alati custom konto luua, millel on need õigused, mis vaja just selle rakenduse piires (turvalisus). Ka on võimalik eristada paremini Task Manageri alt, missugune tööprotsess on mingi rakenduse oma (kõik on ju wp3p.exe).

Edu!

Kuidas saada DLL kätte GAC -st

Ühele kindlale probleemile lahendust otsides sattusin hoopis huvitava nipi otsa. Kas teie teate, kuidas GAC -i (Global Assembly Cache) installitud DLL kätte saada? Näiteks Sharepointi puhul on hunnik DLL -e installitud ainult GAC -i ja vahest oleks soov Reflectoriga näiteks uurida, et mis tagataustal toimub.

Igatahes pole mina selle peale varem väga mõelnud. Vahest on tulnud ette, et mugav, mõnus ning harjumuspärane oleks saada "kopeerida" windows exploreri kaudu GAC -s (C:\Windows\assembly) olevat dll -i, aga ei ole kuidagi õnnestunud. Ja seejärel on see üritus pooleli jäänud ning läinud otsima DLL -i mujalt kettalt.

Igatahes on olemas väga lihtne ja elementaarne ja peidetud viis DLL -i kättesaamiseks. Tuleb välja, et kui minna command promptiga c:\Windows\assembly\Gac aadressile, siis on võimalik edasi surfata mõõda katalooge ja soovi korral ka õige versiooni DLL välja kopeerida.

Järgnevad screenshotid illustreerivad tegevust. Alustame System.dll -i välja kopeerimist GAC -st.

Ja kui te ei usu command line -i teksti "1 file copied.", siis Windows Explorer kinnitab.

Õpetus ise asub muidu siin.

Harva esinev probleem WCF -i teenuse metaandmete pärimisel

Mõnda aega tagasi sattusin arendades huvitava olukorra ette. Nimelt on võimalik WCF -i teenustelt saada lisa metainfot teenuse kohta XSD näol (andme tüüpide kirjeldused näiteks). ?wsdl päring ise ei ole just kõige põhjalikum. Lisades urlile ?xsd=xsd0 saab tavaliselt schema tüüpide kirjeldused, mis on kasutusel teenuses.

 Veel on olemas ?xsd=xsd1 (vahest ka xsd2). Veel infot on siin.

Igatahes on võimalik lisaks metainfot hankida nii. Nüüd, võib tekkida olukordi, kus te ei saa seda metainfot kätte. Näiteks võib juhtuda, et te jooksutate oma veebi rakendust application pool -s, mis kasutab jooksutamiseks muud kontot kui aspnet või Network Service (nende puhul probleemi ei ole, kuna vastavad õigused olemas).

Igatahes, kui teil peaks juhtuma selline probleem, siis abi leiate siit.

Ja kui ei viitsi minna lugema sinna, siis lühidalt on probleemiks õiguste mitte omamine "%WINDIR%\temp" kataloogile. Vajalikeks õigusteks on list folder/read data on this folder only. See võimaldab näha faile, mis temp kataloogis on, aga ei võimalda lugeda faile, mille omanikuks on teised kontod.

SQL Server 2005 - instantsi collationi muutmine

<Täiendus> - 25.11.2007 (õhtul)

Pärast mõningast testimist sain siiski tööle ka collationi muutmise command line -lt. Lisan siia omapoolsed seletused, millele tähelepanu juhtida - vastasel juhul ei saa tööle asja.

Command line -lt käivitage:

start /wait <PATH TO SETUP>\setup.exe /qb INSTANCENAME=<InstanceName> REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=<NewSAPassword> SQLCOLLATION=<NEW COLLATION>

Kusjuures <INSTANCENAME> puhul on tegu ainult instantsi nimega, mitte ARVUTINIMI\INSTANTSINIMI (mina rumal sisestasin seda)

<SAPWD> ei ole olemasoleva SA parool, vaid uus SA parool. 

<NEW COLLATION> on näiteks SQL_Latin1_General_CP1_CI_AS.

Ja lõpetuseks, see on kiirem kui uuesti installimine, juhul kui te olete värskelt andmebaasi lisanud aga vale collationiga.

Lisaks setup -i vingerbusside kohta lugege siit.

</Täiendus>

Täiesti mittetriviaalne soov tekkis täna - muuta sql server 2005 instantsi collationit. Sai installeritud värske SQL server 2005 ühe virtuaalse masina peale, kuid kahjuks vale collationiga. Et vältida suurt tülikat tegevust ning uninstalleerida värske sql server 2005 -e instants ning uus installeerida, mõtlesin et ehk on lihtsam viis vahetada collationit instantsil.

Enne jätkamist seletaks väga üldiselt collationi mõtte MS SQL Server -s. Collation on reeglitekogum, kuidas sorteerida, võrrelda, teisendada unicode-nonunicode vahel.

Leidsin Microsofti artikkli MSDN libraris collationi vahetamise kohta instantsi tasemel, kuid kahjuks seda toimima ei saanud. Põhjus on seni teadmata (setup katkeb suht alguses teadeteta).

Igatahes järeldus ja soovitus kõigile - kui te soovite vahetada SQL Server 2005 -e instantsi collationit, siis lihtsaim viis on backupida ära kõik oma andmebaasid ning seejärel uninstallida ja uuesti installida sql serveri instants muudetud seadetega. Seejärel restorida baasid tagasi.

On olemas veel Change nupp, mida leiad Control Panel -> Add/Remove Programs -> SQL Server 2005. Kahjuks küll ei õnnestunud ka selle käigus collationit seada.

Igatahes pole ülisuurt vahet uuesti installeerimisel või siis MSDN librarys asuva tegevusega (command line -lt master -i reinstallida). Niikuinii pead kõik andmebaasid kokku pakkima ja eemaldama instantsist, seejärel reinstallima master -i ning uuesti baasid lisama. 

Siin on veel üks link collationi vahetamise teemal, temal igatahes õnnestus see.

Ahjaa, palju-palju lihtsam on vahetada andmebaasi collationit (Alter Database abil):) Tehke parem seda.

VSTS2008 ja .Net 3.5 välja

See nädal on nii kiire olnud,et magasin maha uudise - Visual Studio Team System 2008 (sealhulgas siis TFS 2008 ja Visual Studio 2008) ja .Net 3.5 -e RTM -i jõudmise kohta. See juhtus 19 novembril. Kes veel ei tea, siis siin on informatsioon teile lugemiseks.

• Visual Studio 2008
• Visual Studio 2008 Express Editions 
• .Net 3.5
• Scott Guthrie teadaanne (mõningate featurede kirjelduste ja linkidega)

Lisaks tuli välja nädala sees ka Visual Studio 2008 SDK 1.0 ja Visual Studio 2008 Shell.

Minu jaoks on SDK puhul põnevaimad DSL tools (domeeni keelte loomine, graafiliste disainerite loomine, mis genereerib koodi), Sandcastle (dokumentatsiooni genereerimine koodi kommentaaride põhjal), ...

Olen endale need eraldi virtuaalse masina peale paigutanud ning loodetavasti jõuan varsti C# 3.0 -st rääkida.

Näidilahendus: Usercontrolid Sharepointi arenduses

Ajendatult eilsest arutelust ühe Sharepoint 2007 arendajaga sai mulle ülesandeks luua pisikene demo kood sellest, kuidas kasutada Sharepointi WebPartide sees ASP.NET –i Usercontrole ja Layouts kataloogi lisada uus leht. Seega, minu postituse sisuks on luua uus lehekülg Sharepointi Layouts kataloogi alla, millel asuks uus WebPart ning see webpart laeb endale sisse usercontroli. Arenduse jaoks loon ma pideva paigaldamise lahenduse (iga build visatakse kogu krempel Sharepoint 2007 –sse, et saaks minna proovima).

Miks kasutada ASP.NET –i Usercontrole?

Erinevalt WebPartidest, võimaldavad Usercontrol -d mugavalt luua kujunduse Visual Studio -ga ning arendada selle taha koodi. Ka saab luua mitmeid Usercontrole, et oma koodi (ja staatilist kujundust) jaotada loogiliselt. Näiteks on teil atrikklite vorm, siis artikkli sisu võiks olla üks usercontrol ja kommenteerimise võimalus, eraldi usercontrol. Webpartide kasutamise puhul, tuleb kogu tegevus koodis ära teha (kaasaarvatud disain). Tõsi, vahest niisugune tegevus on vajalik - näiteks dünaamiliste vormide puhul (kujundus on dünaamiline), aga tihedamini on siiski tegu täiesti staatilise disainiga ja palju mõnusam on saada see kujundus seada kasutades Visual Studio disainerit koos usercontrolidega.

Asume lahenduse kallale.

Lahendus

Samm 1 - VS lahenduse ülesehitus

Mina eelistan antud juhul luua veebirakenduse projekti põhjal uue veebi projekti. Antud Visual Studio 2005 laiendus võimaldab luua veebi projekti, mille kompileerimisel on tulemuseks üks DLL kogu koodi kohta (ehk meil on miskit paigaldada Sharepointi). Algselt Visual Studio 2005 -ga antud projektitüüpi kaasas ei olnud, kuna muutus ASP.NET –i veebi kompileerimismudel. Alates VS2005 SP1 -st on see jällegi võimalik valik (enne SP1 -te oli eraldi installer selle jaoks). Samas antud variandi juures oleme sunnitud ise paigaldusscriptid looma, et Sharepoint 2007 –sse lahendus viia.
Teine variant saavutada sama tulemust on Sharepointi webparti projekti ja veebirakenduse projekti malli kasutades nii, et usercontrol –de jaoks on veebiprojekt ja sharepointi webparti jaoks on temale mõeldud malli põhjal loodud projekt. Eelis Sharepointi Webparti projektil on see, et genereeritakse valmis ka korralik paigalduspool webparti kui feature installimiseks.

Mõeldes veel teise variandi peale, peab tunnistama, et see on ka suurepärane lahendus, kui on vaja mitmeid webparte luua ning mõistlik sealjuures oleks ju usercontrolid paigutada ühte projekti. Webparti projektile endale kahjuks usercontroli lisada ei saa.

Kindlasti ei ole need kaks varianti ainukesed lahenduse ülesehituse tüübid. Eks lahenduse ülesehitus ning paigalduskeem luuakse ikka vastavalt projekti nõuetele.

Igatahes antud postituses räägin mina esimesest variandist, samas vastan küsimustele heameelega ka laiemalt.

Samm 2 - Projekti ülesehitus

Projekti ülesehituse loomisel proovime järgida Sharepointi enda ülesehitust (vaadake C:\Program Files\Common Files\Microsoft Shared\web server extensions\12), et hiljem oleks lihtsam paigaldada sharepointi keskkonda.

Samm 3 - UserControl, WebPart, Layout -i leht

Esimesena lisame vajaminevad failid (DemoUserControl.ascx, DemoUserControlPart, DemoPage) projekti õigetesse kohtadesse ning tulemuseks on all järgnev pilt.

Tähtis on täheldada, et minu lahenduse puhul kataloog ei ole vastavuses nimeruumiga, vaid on puhtalt struktureerimiseks. Nimeruumiks on klassidel “Taavi.Demo.SPUserControls”. Nimeruumid hakkavad hiljem konfigureerides suurt rolli mängima.
Ka on igal sharepointi kataloogil oma alamkataloog (olgu projektinimi või firmanimi vms), et suudaksin eristada enda faile Sharepointi default failidest – nii saan ka luua sama nimega faile ja ei muuda Sharepointi standard käitumist.

Järgnevalt asuks usercontroli kallale.

Samm 3.1 – DemoUserControl

Plaanin luua ühe lihtsa kisamisvormi, millel on mõned label -id, kaks teksti kasti – eesnimi ja sõnum ning nupp, millele vajutades lendab javascripti alert, kus eesnimi ja sõnum kirjas.

Ainult disainimisest muidugi ei piisa, vaja on ka veidi javascripti ja c# -i.
Esiteks on vaja luua javascripti funktsioon – Kisa(), mis saab sisse eesnime ja sõnumi HTML –i elementide ID –d ning leiab nende abil väärtused. Antud väärtused edastab kliendile Alert() funktsiooni abil.

<script language="javascript" type="text/javascript">
function Kisa(eesnimiId, sonumId)
{
    eesnimi = document.getElementById(eesnimiId).value;
    sonum = document.getElementById(sonumId).value;
    alert(eesnimi + " kisab: " + sonum);
}
</script>

Teiseks on vaja nupule lisada C# -s attribuut, et onclick sündmuse peale kutsutaks välja kliendi pool Kisa meetod õigete ID –dega.

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);

    string jsKisaCall = string.Format(
            "BLOCKED SCRIPTKisa('{0}', '{1}')",
            txtEesnimi.ClientID,
            txtSonum.ClientID
        );
    btnKisa.Attributes.Add("onclick", jsKisaCall);
}

Ka soovin tähelepanu pöörata Assembly tag –le usercontroli disaini faili source –s, see on vajalik, et leitaks ülesse lehe taga asuv kood.

<%@ Assembly 
    Name="Taavi.Demo.SPUserControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" 
%>

Siinjuures tuletan meelde kuidas leiti dll –i PublicKeyToken -i väärtus (selleks et paigutada GAC –i DLL –i, peab see olema allkirjastatud).

Samm 3.2 – UserControlDemoPart

WebParti juures tuleb laadida õige usercontrol lehe sisse ning lisada kontrollide kollektsiooni. Selleks override –me CreateChildControls meetodi ning seal laadime usercontroli asukoha järgi sisse.

private UserControl userControl;
protected override void CreateChildControls()
{
    string userControlPath =
        @"/_controltemplates/UserControlDemo/DemoUserControl.ascx";

    TraceContext trace = HttpContext.Current.Trace;
    try
    {
        this.userControl =
        this.Page.LoadControl(userControlPath) as UserControl;
        trace.Write("UserControl (" + userControlPath + ") Load successful.");
    }
    catch (Exception exc)
    {
        trace.Write("UserControl (" + userControlPath + ") Load failed.");
        trace.Write("Exception: " + exc.ToString());
        throw new ConfigurationErrorsException(
                "Either 'DemoUserControl.ascx' is not in ControlTemplates folder or assembly is not in GAC!.",
                exc
            );
    }
    this.Controls.Add(this.userControl);
}

Samm 3.3 – DemoPage

Demo lehe juures tuleb täheldada kahte aspekti:

• Esiteks MasterPage –i aadress peab olema Sharepointi masterpage –i url.
• Selleks, et kasutada lehel usercontroli (.ascx failis) tuleb ka Register tag –iga teatud nimeruum kättesaadavaks teha (ja mitte unustada sealjuures Assembly kirja panna).

Hetkel, antud lehel puudub kood. Kui te soovite koodi lisada lehele, siis peab see tulenema LayoutsPageBase –st. Juhul, kui soovite luua uut sisenemislehte, on tegu veidi keerulisema ettevõtmisega, kuna kasutaja, kes sinna läheb on autentimata, aga LayoutsPageBase nõuab autenditut kasutajat. Appi tuleb UnsecuredLayoutsPageBase J Mõni teine kord pikemalt login lehest.

Samm 4 - Paigaldus (deployment)

Paigalduse juures eeldan, et võin uue feature koos kõikide failidega lisada Sharepointi jagatud failide hulka (sest sinna paigutab feature deployment kõik failid). Üldiselt peaks feature kaudu deployment olema sobiv, teil on alati võimalik mingi feature teha kättesaadavaks kõigile ja failid saab paigutada alamkataloogidesse (nagu mina seda teinud olen, kõik asuvad DemoUserControl kataloogides). Featurel endal on ka skoop olemas, millega piiratakse Sharepointi sees funktsionaalsuse kasutamise võimalus. Samas, kui teil on tegu serveriga, kus on palju Sharepointi lahendusi ning te ei soovi faile kõigile paigaladada, siis tasub mõelda mingi muu paigaldamismeetodi peale.

Samm 4.1 - Feature konfiguratsioon

Feature konfiguratsioon koosneb kolmest failist, mis asuvad Features\UserControlDemo kataloogis.

feature.xml

<Feature
  Title="DemoUserControlPart" Id="e68f6108-0750-4eeb-afa0-497dce63562d" 
  Description="DemoUserControlPart" Scope="Site" Hidden="false" Version="1.0.0.0"
  xmlns="http://schemas.microsoft.com/sharepoint/" 
   >
  <ElementManifests>
    <ElementManifest Location="elementManifest.xml" />
  </ElementManifests>
</Feature>

elementManifest.xml

<Elements  xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="DemoUserControlPart" List="113" Url="_catalogs/wp" >
    <File Url="DemoUserControlPart.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="DemoUserControlParts"></Property>
    </File>
  </Module>
</Elements>

DemoUserControlPart.webpart

<webParts>
  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
    <metaData>
      <type name="Taavi.Demo.SPUserControls.DemoUserControlPart" />
      <importErrorMessage>Cannot import DemoUserControlPart.</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name="Title" type="string">DemoUserControlPart title</property>
        <property name="Description" type="string">DemoUserControlPart plugin for Sharepoint.</property>
      </properties>
    </data>
  </webPart>
</webParts>

Iga fail kirjeldab järjest madalama taseme “objekti” omadused. Kuna tegu on väga lihtsa webpartiga, mille featurina paigaldame, siis ülemiste konfiguratsioonide kohta detailsemaid seletusi ei anna.

Samm 4.2 – Paigalduse konfiguratsioon

Paigalduse konfiguratsioon koosneb kolmest failist:

• manifest.xml, mis on n-ö installeerimisjuhend
• Taavi.Demo.SPUserControls.ddf - on pakketeerimisjuhend .cab faili loomiseks (tulemuseks on cab fail, mis nimetatakse ümber .wsp –ks)
  • Kirjeldab ära, mis failid ja kuhu tuleb need panna .cab konteineris
• Setup.bat – käivitab kõik vajaminevad tegevused paigaldamiseks
  • Setup.bat vajab mõnede parameetrite seadistamist (.bat failis), ja pärast seda oskab suurepäraselt feature installida sharepointi. Nendeks parameetriteks on: feature GUID, .wsp paketi nimetus, Sharepointi web –i ja saidi asukoht (url)
  • Oskab uninstallida vana feature, enne kui installib
  • Teeb alati IISreset –i lõpetuseks (kuna tavaliselt pannakse DLL –d GAC –i)

Ma jätaks nende failidega tutvumise juba source –i uurimise ülesandeks.

Samm 4.3 – Buildiga paigaldus

Buildiga paigalduse all mõtlen ma niisugust tegevust, kus iga buildi tulemuseks on lahenduse ülespanek Sharepointi, et saada testida lahendust läbi veebiliidese ning teada, et paigaldusprotsess toimib ilusti ning midagi katki ei ole. Ma avatasin, et Sharepointi lahenduste juures on niisugune lähenemine mõistlik, kuna arendaja buildib tavaliselt siis, kui arvab, et funtskionaalsus on valmis saanud (või mingi staadiumis, kus soovib tulemust näha) ning kõik toimingud paigalduseks nagu feature konfiguratsiooni uuendamine jm ka tehtud (varem pole mõtet, kuna puhas kompileerimine erilist infot ei anna, mida muidu ei saaks).

Buildiga paigaldamiseks kasutan ma Visual Studio 2005 post-build evente. Iga kompileerimise järel tehakse järgmine tegevus:

1. Minna projekti kataloogi command line –l
2. Kasutades makecab.exe –t luua Taavi.Demo.SPUserControls.ddf faili põhjal cab konteiner (tegelikult .wsp fail)
3. Kopeerida need bin\Package alla
4. Käivitada paigaldus Sharepointi (setup.bat /ui)

Koodis näeb see siis järgnev:

Samm 5 – Tulemus

Antud tegevuse tulemuseks on all oleva ekraanipildi nähtav alert aken, ainult et siis alguses kokku lepitud nõuete kohaselt.

Kokkuvõte

Meie eesmärgiks oli luua uus Sharepointi „leht” Layouts kataloogi, millel on webpart ning mis omakorda laeb sisse usercontroli. Ma usun, et sellega sain ilusti hakkama.

Märkused, mida meeles pidada:

• UserControl –i kasutamine teeb arenduse mõnusamaks ja efektiivsemaks, kui tegu on staatilise disainiga lehe osadega, mida soovitakse taaskasutada, kuna saab kasutada Visual Studio disainerit.
• Layouts lehe puhul MasterPage on Sharepointi Masterpage ja url peab olema vastav (arendamise hetkel kas kopeerida ajutiselt projekti juurde või siis mitte lasta häirida ennast punastest joontest)
• Layouts lehe puhul peab ka alati assembly olema määratud.
• Kui loote koodiga Layouts lehte, siis see peab tulenema LayoutsPageBase -st
• UserControli disainifailis peab olema määratud assembly, milles ta asub (juhul kui tal on kood taga)
• Lahenduse ülesehitust luues, on tark ka mõelda, kuidas paigaldatakse arendus/testi/live keskkonda (erinevad meetodid paigaldamiseks, Sharepointi jagatud failid)
  Arenduses võib alati feature kaudu paigaldamist kasutada, kuna tavaliselt arendate ju omas masinas

Sharepointi baastõdesid ma ei seletanud, aga otsides leiate nende kohta materjali kindlasti ohtralt

Lahenduse kood