Ontwikkelen voor Sharepoint zonder Visual Studio op Windows Server

Ik programmeer wel eens wat voor Sharepoint om mij te ondersteunen bij het oplossen van incidenten of voor rapportage. Het vervelende is dat ik altijd binnen een Virtual PC VM zat te kloppen, wat nu net even wat minder presteert (wat een understatement) dan de fysieke machine. Nu blijkt dat het ook prima mogelijk is voor Sharepoint te ontwikkelen op een client OS. Dit door gebruik te maken van de mogelijkheden binnen Visual Studio voor remote debugging en development. Deze post gaat daar verder op in.

Installatie Visual Studio

Voor het ontwikkelen maken we uiteraard gebruik van Visual Studio. Ik gebruik in dit document de Team Suite editie. Je kunt echter ook de Professional editie gebruiken. Alle andere versies ondersteunen geen remote debugging/development dus kunnen in het scenario in deze post niet gebruikt worden.

Het installeren van Visual Studio spreekt voor zich. Ik kies voor de volgende installatie, maar je kunt uiteraard zelf bepalen welke componenten je wel of niet wilt gebruiken, als je maar minimaal 1 van de language tools installeert zodat je de IDE hebt:

Na de installatie is het aan te raden Service Pack 1 te installeren (http://www.microsoft.com/downloads/details.aspx?FamilyId=27673C47-B3B5-4C67-BD99-84E525B5CE61&displaylang=en ), en Windows Update te configureren om de laatste updates te downloaden (SP1 kan ook via Windows update binnengehaald worden). Voordat je SP1 installeert moet je echter eerst de Service Pack Preparation tool (http://www.microsoft.com/downloads/details.aspx?FamilyId=A494B0E0-EB07-4FF1-A21C-A4663E456D9D&displaylang=en ) uitvoeren.

Vervolgens installeer je de Visual Studio 2008 extensions for Windows SharePoint Services 3.0 v1.2 http://www.microsoft.com/downloadS/info.aspx?na=40&p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=b2c0b628-5cab-48c1-8cae-c34c1ccbdc0a&u=http%3a%2f%2fwww.microsoft.com%2fdownloads%2fdetails.aspx%3ffamilyid%3d7BF65B28-06E2-4E87-9BAD-086E32185E68%26displaylang%3den (of de CTP van 1.3 als je het aandurft, of X64 draait http://www.microsoft.com/downloadS/details.aspx?familyid=B2C0B628-5CAB-48C1-8CAE-C34C1CCBDC0A&displaylang=en ). Het is niet vereist, maar biedt Sharepoint project- en item templates. Deze extensions draaien alleen op Server Operating Systemen, maar daar is een truc voor. Draai gewoon het volgende commando om een registry key aan te maken om de MSI te misleiden:

REG ADD 'HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0' /v Sharepoint /t REG_SZ /d Installed8

Nu kan je de extensions ook installeren op Vista of Windows 7. De installatie spreekt voor zich (Let wel… v1.2 draait alleen op x86).

Installeren Virtual PC

Installeer nu Virtual PC 2007 SP1 en een Sharepoint VM. We gaan code kloppen op onze lokale machine maar de project bestanden komen in de VM te staan. Verder gaan we de code draaien en debuggen op de VM via remote debugging. Hiervoor moeten we een netwerk verbinding hebben met de VM. Je wilt echter niet dat een VM contact kan leggen met het netwerk waar je developer PC inhangt. In Hyper-V en Virtual Server hebben we zoiets als een host only network, waar de VM's contact hadden met de host, maar niet met andere netwerken waar de host een verbinding mee kan leggen. In Virtual PC moet je echter wat meer doen om dit voor elkaar te krijgen.
Om een host only netwerk op te zetten tussen je VM host en je VMs in Virtual PC kan je gebruik maken van de loopback adapter. Om deze te kunnen installeren onder Vista of Windows 7 moet je even zoeken. Je kan gebruik maken van devcon.exe (devcon.exe install %windir%\inf\netloop.inf *msloop8 ) of je kan hem toevoegen gebruik makend van Device Manager. Hiervoor moet je echter de 'Add Legacy Hardware' optie gebruiken:

Configureer vervolgens ip settings voor de loopback adapter en configureer de VM in Virtual PC om gebruik te maken van de loopback adapter:

Stel het ip adres van de VM in op hetzelfde subnet als je hostip van de loopback adapter en pingen maar!
Maak vervolgens een share aan voor '%Program Files%\Common Files\Microsoft Shared\web server extensions\12\ISAPI' in de VM, en maak daarnaast nog een project folder aan waar vanuit je de debug builds wilt gaan draaien, en share deze ook. Map de share voor de ISAPI folder op de developer PC.
De ISAPI folder bevat de objectmodel dlls, die je nodig hebt om als REFERENCE te dienen in je Sharepoint VS projecten.

Configuratie remote debugging

Nu de verbindingen gelegd zijn en de shares zijn aangemaakt is het tijd om remote debugging te configureren. Dit gaat als volgt:

Installeer de remote debugger http://www.microsoft.com/downloads/details.aspx?FamilyID=440ec902-3260-4cdc-b11a-6a9070a2aaab&displaylang=en#filelist

Na de installatie start automatisch het debugger configuratie venster, waarin je eigenlijk alleen maar hoeft aan te geven of je de debugger als Service of als Windows applicatie wilt draaien. Ik draai het als windows applicatie, maar je kan hem ook als Windows Service draaien.

Ik had met de debugger als Service wel wat problemen met het verbinden met de debugger. Hier kom ik later op terug. Ook heb je als Windows Service geen console output als je een console applicatie debugged. Het window is hidden, omdat de Service in de background draait, en elk childprocess ook als backgroundprocess wordt opgestart. Nu moet je voor een Windows Service een service account opgeven. Nu kan je kiezen voor Local System, echter werkt dit niet als je developer PC in een ander Domain hangt dan de VM, wat meestal zo is. Het service account wat je opgeeft heeft administrator rechten nodig en het 'Logon as Service' user right. Nu moet er een wederzijds vertrouwen zijn tussen de developer pc en vm. De remote debugger moet zich kunnen authenticeren met de developer pc en vice versa. Als je developer pc of laptop (in mijn geval) dus lid is van het ene domein en de VM van het andere, heb je een uitdaging. Een trust aanmaken gaat vaak niet. Zeker niet als je laptop of pc lid is van het bedrijfsdomein en de VM van een eigen testdomeintje. Nu is er een oplossing voor. Je zorgt er gewoon voor dat er in het testdomein op de VM een account bestaat met dezelfde accountnaam en hetzelfde wachtwoord als het account waarmee je jezelf aanmeldt op de laptop of pc. NTLM zal ervoor zorgen dat er geauthenticeerd kan worden (http://support.microsoft.com/kb/102716)

Ik start de debugger dus als Windows applicatie. De vereisten voor authenticatie zijn hetzelfde. De gebruiker die de debugger start, moet zich kunnen authenticeren bij de developer pc en de gebruiker die visual studio start, moet zich kunnen authenticeren bij de VM. Ik gebruik bijna altijd PSEXEC van SysInternals, om de debugger bij het aanmelden op te starten (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx)

PSEXEC /d /u <domain>/<user> /p <password> "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe"8

Je kan ook Secondary Logon gebruiken om de debugger te starten:

Runas /noprofile /user:<domain>/<user> "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe"8

Nu de debugger draait, moet de firewall nog geconfigureerd worden op zowel de client als de server. Je krijgt dan vervolgens vanzelf de firewall meldingen en UAC meldingen. Dit gaat het makkelijkst door in Visual Studio te kiezen voor Debug > Attach to Process Geef in het venster de VM server naam op en als het goed is krijg je dan de benodigde firewall waarschuwing op de client. Mocht je nog problemen hebben; de porten die geopend moeten worden zijn: DCOM (TCP Port 135) en IPSEC (UDP 4500 / UDP 500) http://msdn.microsoft.com/en-us/library/h0d7tte4(VS.80).aspx )
Hierbij is het belangrijk de echte servernaam te gebruiken, want je kan de debugger niet benaderen op IP. Je moet er dus ook voor zorgen dat name resolutie plaats kan vinden. Zet de VM dus bijvoorbeeld in je HOSTS file.

Voor de server zal je de vereiste firewall instellingen moeten zetten, maar aangezien het een afgeschermde development VM is, schakel ik de firewall gewoon altijd uit. Maar mocht je het aan willen laten staan, is de File and Printersharing firewall rule genoeg. Als de firewalls zijn geconfigureerd moeten we alleen nog de .NET code access security (http://msdn.microsoft.com/en-us/library/930b76w0(VS.71).aspx) op de VM bijwerken. .NET heeft een mechanisme het uitvoeren van code te beveiligen. Dit heeft veel weg van de manier hoe Internet Explorer werkt met security zones. Het uitvoeren van .NET code van een fileshare heeft te maken met andere policies als het uitvoeren van code op de lokale machine. Met remote debugging zal de debugger de code starten vanaf de locatie die aangegeven staat in de projecteigenschappen. Je zult zo zien dat dat een fileshare op de VM is, namelijk de share die we in een eerder stadium hebben aangemaakt voor de VS build bestanden. Deze share valt in een andere security zone, waardoor .NET een SecurityException zal genereren als er code gestart wordt die een hoger trustlevel vereist (wat met sharepoint assemblies vaak zo is) dan de zone waarvandaan het gestart wordt heeft toegewezen gekregen.

Een voorbeeld daarvan is:

System.Security.SecurityException was unhandled

Message: Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed.

Om dit te verhelpen moet je de caspolicy aanpassen, zodat jouw locatie wel het juiste trustlevel heeft. Dit doe je door caspol.exe te gebruiken. Deze tool is te vinden in de directory van het .NET framework 2.0 (%Windir%\Microsoft.NET\Framework64\v2.0.50727 bijv.)
Let op… Je gaat op de VM dus een share trusten van de VM zelf.

Het commando wat je op de VM uit moet voeren is als volgt:

CasPol.exe -m -ag 1. -url "\\<vm>\<visual studio debugshare>\*" FullTrust8

In mijn geval was dat:

CasPol.exe -m -ag 1. -url "\\192.168.0.100\Visual Studio\*" FullTrust8

Nu kun je jouw eerste applicatie gaan debuggen!! J

Maak eerst een project aan voor bijvoorbeeld een console application. Als je dit project hebt aangemaakt, vraag je de properties van het project op in de solution explorer. Stel vervolgens in de Build sectie in dat je de build output wilt wegschrijven naar de share waarvoor je zojuist de CAS policy hebt gewijzigd:

Stel vervolgens in de Debug sectie de remote debugger in. De remote debugger registreert zich als pipe server. Normaal gesproken, als je hem als windows applicatie opstart, wordt de server gestart met de qualifier <username>/<domain>. Ik verwachte hetzelfde gedrag te zien met het starten als Windows service. Je zou de debugger moeten kunnen benaderen onder <username>/<domain>@<server>. Echter met de remote debugger als Windows Service, werkt het echter niet. Een snelle kijk in de named pipes lijst via Sysinternals pipelist liet mij gelukkig zien hoe deze dan wel geregistreerd stond (Gek genoeg niet in de utilities index, maar de functionaliteit zal wel overgenomen zijn door een andere tool. Ik weet alleen niet welke. Pipelist is iig te vinden op http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx ):

De debugger stel je vervolgens in de Debug sectie in de project properties in als <domain>\<user>@<servernaam> (of svc=msvsmon90@<servernaam> als je als Windows Service draait).

Vervolgens moet je uiteraard als je sharepoint code wilt gaan kloppen de juiste References leggen. Dus ga naar References > Add reference in de solution explorer en kies voor Browse tab. Browse naar de Drive Mapping die je in een eerder stadium had aangemaakt voor de ISAPI folder op de VM. Hier kan je vervolgens de binaries kiezen die de juiste namespaces bevatten. Voor WSS 3.0 kan je die vinden in het volgende overzicht: http://msdn.microsoft.com/en-us/library/ms453225.aspx
De meest gebruikte zijn te vinden in Microsoft.Sharepoint.dll:

Schrijf nu een stukje voorbeeldcode met een breakpoint en druk op F5… VOILA… remote development en debugging werkt! Zo bewijzen de volgende screens..

Een breakpoint in VS:

En de Output op de VM: