Zoals is te lezen ben ik onlangs overgestapt naar Orchard als blogging platform. Qua interface en beleving bevalt het me tot nu toe prima. Het is een redelijk snel platform en laat zich eenvoudig installeren, mede dankzij het WebMatrix platform van Microsoft.

Hoewel de installatie redelijk goed ging, waren er toch enkele haken en ogen die ik tegen kwam. Om deze reden beschrijf ik de genomen stappen even stuk voor stuk.

Ten eerste moet WeMatrix worden opgestart. Op het startscherm kan dan worden gekozen voor de optie Site From Web Gallery, we willen immers een Orchard site maken en dat is een type site dat door WebMatrix wordt ondersteund. Uiteraard kan er ook voor een Joomla, WordPress, Umbraco of ander systeem worden gekozen.

Zodra het vervolgscherm is geladen zoeken we naar het Orchard template.

Na het invullen van de site naam kan er op Next worden gedrukt. Door in het vervolgscherm op I Accept te drukken zal het template worden gedownload en de site worden aangemaakt. Dit wordt bevestigd in nog een vervolgscherm.

Uiteindelijk zul je in een WebMatrix scherm verschijnen waar eigenlijk alles in kan worden beheerd. De interface biedt (nog) niet enorm veel opties, maar op zich voldoende om mee uit de voeten te kunnen.

Aan mij was de taak om een applicatie te schrijven welke informatie van SharePoint (Wiki sites) website kon wegschrijven naar HTML bestanden met een bepaalde opmaak.

Niks aan de hand, ware het niet dat ik op m’n Windows 2008 VM zowel MOSS 2007 als Visual Studio 2010 had geinstalleerd. Bij het toevoegen van de benodigde references kwam ik er ineens achter dat ik de SharePoint 2007 DLL’s niet kon vinden in de lijst. Het is ook een bekend ‘probleem’, aangezien het ook op Connect staat geregistreerd als issue. Er staat ook dat het probleem is geescaleerd naar het betreffende team, maar dat was al op 20 november 2009. Jammer dat dergelijke calls dan niet verder worden bijgewerkt, want blijkbaar is het antwoord gewoon ‘zoek het lekker zelf uit’.

Gelukkig kan ik dat ook prima zelf uitzoeken.

De dll’s staan namelijk gewoon in de map C:\Program Files\Common Files\Microsoft Shared\Web Server Extenstions\12\ISAPI.
Door de Browse knop te gebruiken bij het Add Reference scherm kan dan gewoon, net als vroeger, de betreffende dll worden geselecteerd, bijvoorbeeld Microsoft.SharePoint.dll.

Het werkt dan allemaal prima, maar is wel jammer dat dit niet standaard wordt ondersteund. Het is al erg genoeg dat we met Visual Studio 2008 ook al niet met SharePoint 2010 kunnen werken.

Tijdens het ontwikkelen van een van m’n WP7 applicaties liep ik er tegenaan dat er naar een andere pagina moest worden genavigeerd. Je kunt, naar mijn mening, namelijk niet alles binnen een Pivot- of Panorama-control plaatsen. Het kan ook zijn dat dit nog een ouderwetse gedachtengang is, maar daar ben ik nog niet achter.

Het probleem was echter dat navigatie niet echt (goed) is geimplementeerd binnen WP7 of Silverlight. Omdat dit toch moest binnen mijn applicatie heb ik hier een oplossing voor moeten verzinnen. Gelukkig was ik niet de enige met dit probleem en kwam ik op Stack Overflow (link ben ik kwijt) al snel op een antwoord waar ik mee kon werken.

Het idee is dat je je views laat afleiden van een BaseView. In deze BaseView definieer je dan de navigatie methoden, zodat alle views dit kunnen doen. De navigatie wordt gedaan aan de hand van een navigatie object en het registreren op de wijzigingen binnen dit object. Door gebruik te maken van de Message bus die je gratis bij MVVM Light krijgt is dit eenvoudig te realiseren.

Eerst dient er een object te worden gemaakt waar de pagina en querystring in kan worden gestopt. Dit is bij mij een nieuwe klasse welke er als volgt uit ziet:

Momenteel zit ik bij een klant waar iedere ontwikkelaar z’n gang kan gaan binnen een vooraf geinstalleerde VM. Helemaal ideaal natuurlijk, zo weet je zeker dat alles goed werkt binnen het netwerk, zeker wanneer er enkele ‘speciale’ dingen moeten worden ingesteld, zoals een proxy, certificaten, ADFS, etc.

Nu wilde ik onlangs een project uit TFS halen om daar wijzigingen in aan te brengen. M’n workspace had ik ingesteld op C:\Projecten\. Zo kan ik via de Windows Verkenner snel naar die map toe gaan. Hoewel dit tegenwoordig niet meer direct noodzakelijk is, is dit eigenlijk een gewoonte van me geworden.

Bij het ophalen van het project kreeg ik een volgende melding:

The path C:\Projecten\ is already mapped in workspace MACHINENAME;DOMEIN\OTHERUSER

Aangezien ik nog niet zo heel bekend ben met TFS en de onderliggende werking wist ik even niet wat ik hier mee aan moest. Deze VM was helemaal clean en die betreffende gebruiker had zeker nog nooit op deze machine zitten werken. Na wat zoeken kwam ik er al vrij snel achter dat TFS zelf bijhoudt welke gebruikers een project hebben opgehaald. Hier wordt ook bij geregistreerd op welke machine de gebruiker dat gedaan heeft.

Omdat wij allemaal op ‘dezelfde’ VM werken, is de machinenaam ook gelijk. Iedereen maakt immers een kopietje van het origineel. Hierdoor denkt TFS ook dat we allemaal op dezelfde machine zitten te werken en kan ik dus niet dezelfde workspace locatie gebruiken als een collega. Op zich is dat natuurlijk logisch, want dan zou je normaliter bestanden van iemand anders overschrijven, zonder dat die dat door heeft.

Momenteel zit ben ik werkzaam bij een organisatie waar een ISA server als firewall dient en deze heeft een maximum ingesteld op de grootte van de Request Payload. Dit was tot voor kort geen probleem, totdat de ISA server werd geherconfigureerd.

De Request Payload is het stuk code dat de pagina van zichzelf doorstuurt naar een andere (of dezelfde) pagina. Dit is bijvoorbeeld de ViewState en alle controls en waarden binnen een form. Op een bepaalde pagina heel vaak een postback worden gedaan en iedere keer dat dit gebeurde werd de Request groter en groter. Immers, die viewstate wordt groter en alle controls met waarden worden meegestuurd.

Uiteraard wilde ik wel weten hoe groot de requests dan worden. Momenteel stond het limiet ingesteld op 5000 bytes. Dat klinkt wel als veel, maar ik heb er nooit bij stil gestaan hoe groot een request binnen ASP.NET nu eigenlijk normaal is.

Hiervoor heb ik het volgende stukje code maar in de footer van de masterpage binnen de applicatie toegevoegd:

<asp:Content
<span lang="EN-GB" style="font-family:; mso-ansi-language: en-gb;"><font style="font-size: 10pt;"><span><font color="#ff0000">ContentPlaceHolderID="PlaceHolderFooter" ID="ContentFooter" runat="server">
<asp:Literal ID="PageFooterText" runat="server" />
<asp:Literal ID="PageRequestSize" runat="server" />
<asp: Content>

En in de Page Load het volgende:

PageRequestSize.Text = string.Format("Request size: {0} bytes", Request.TotalBytes);

Nu kon ik bij het bezoeken van de pagina’s gelijk zien hoe groot de requests eigenlijk waren.

Sinds gisteren draait m’n weblog niet meer op SharePoint (WSS3.0), maar op het nieuwe .NET CMS genaamd Orchard. Het lokaal installeren was heel eenvoudig met WebMatrix.
Na installatie kon ik gelijk aan de slag met het systeem. Moet zeggen dat het allemaal goed in elkaar steekt en behoorlijk gebruikersvriendelijk is. Installeren van verschillende modules en thema’s kan met 1 klik worden gedaan in de web interface. Dat is wel even wennen als je van SharePoint af komt. Daar moet je eerst allerlei packages installeren, configuraties instellen, etc.

Tot nu toe ben ik dan ook behoorlijk tevreden over het geheel.

Wat wel vervelend is, is dat er momenteel alleen een import (en export) kan worden gedaan met het BlogML formaat.
Op zich mooi dat die functionaliteit wordt aangeboden, maar zelf vond ik het nogal lastig om hier even snel een export voor te maken vanuit SharePoint. Het verkrijgen van de posts, comments en overige zaken is wel prima te doen, echter moet het dan ook in het valide BlogML formaat worden geplaatst. Dit is op zich ook prima te doen, maar ben er halverwege maar mee gestopt omdat ik teveel zaken onduidelijk vond. Heb alles dus maar ge-copy-paste.
Het is iets meer werk, maar zo’n 300 posts zijn nog prima te overzien. Gelukkig heb ik weinig tot geen comments, waardoor eigenlijk alleen de posts over moesten.

Waar ik eerst bijna altijd VMWare Workstation gebruikte, ben ik nu genoodzaakt om toch vaak VMWare Player te installeren. Op zich geen probleem, aangezien VMWare Player tegenwoordig voldoende toereikend is waar ik het voor wil gebruiken (namelijk draaien van ontwikkel images). Hier heb ik momenteel nog niet echt perse de extra features van Workstation voor nodig.

Nu heb ik bij een klant waar ik zit alleen toegang tot het draadloze netwerk. Op zich geen probleem, echter hebben m’n meeste images een Bridged connection op de netwerkkaart. Deze bind zichzelf aan een netwerkkaart op het systeem en dat is niet altijd de draadloze netwerkkaart. Ik kon me herinneren dat dit kon worden geconfigureerd bij Workstation, maar had de optie nog niet gezien bij de gratis Player.

Blijkbaar is het standaard niet mogelijk om de netwerkconfiguratie in te stellen bij VMWare player. Gelukkig kwam ik op een blog post waar exact staat uitgelegd welke stappen moeten worden genomen om dit toch te kunnen doen.

Wat je moet doen is eigenlijk alle bestanden van VMWare Player uit de installer uitpakken en daarna het bestand vmnetcfg.exe uit network.cab kopieren naar de locatie waar VMWare Player staat geinstalleerd.

Omdat het doelloos is om een goed stappenplan slecht te vertalen, hier een quote van de gelinkte blog post:

Afgelopen week was ik aan de slag met het ontwikkelen van een export applicatie voor een bepaalde Wiki website binnen SharePoint. De bedoeling was dat alle inhoud van de Wiki site als HTML en XML moest kunnen worden geexporteerd om zo te kunnen gebruiken in andere systemen.

Een dergelijke applicatie ontwikkelen is inmiddels geen probleem meer en ging dus ook aan de slag zonder de code continu te testen. Pas toen ik dacht klaar te zijn kreeg ik een foutmelding bij het openen van de SPSite, iets als (code kopie van StackOverflow)

`System.IO.FileNotFoundException : The site https://website/ could not be found in the Web application SPWebApplication Name=SharePoint - 80 Parent=SPWebService. at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)
at Microsoft.SharePoint.SPSite..ctor(String requestUrl)

In de gelinkte post van StackOverflow staat ook gelijk wat het probleem is.
Het probleem bij mij was namelijk dat de geinstalleerde Sharepoint 2007 versie 64-bits was. De console applicatie (en later de WPF applicatie) werd gebuild als een 32-bits assembly. Blijkbaar mag een 32-bits assembly niet met een 64-bits Sharepoint praten. Als je er over na gaat denken, klinkt dat ook wel logisch, echter had ik er op dat moment nog niet bij stil gestaan.

Dit geldt trouwens alleen maar voor externe applicaties. Wanneer je een webpart, feature, timerjob of iets anders maakt dat ‘in’ SharePoint werkt, dan geldt dit probleem niet. Bij gebruik van WSP Builder moet dan wel de 64-bits cablib worden gebruikt, waarschijnlijk om dezelfde reden als die ik nu zelf heb ondervonden.

Vaak wanneer ik aan het ontwikkelen ben begin ik eerst lokaal met een klein project. Deze groeit uiteindelijk uit in een iets groter project waar nog wat wijzigingen in plaatsvinden en uiteindelijk wordt het dan het product wat je voor ogen had. Tijdens deze ontwikkeling wil ik dan wel altijd versiebeheer hebben, zodat alles geborgd is.

Voor m’n prive projecten gebruik ik inmiddels al een tijdje Mercurial en ben daar ook enorm tevreden over. Zeker met de plug-ins welke voor Visual Studio worden aangeboden is het goed werken en heb je de hele commandline bijna niet meer nodig.

Wat ik wel vervelend vond is dat het me nog niet was gelukt om een lokale repository te verplaatsen naar een centrale repository en die dan leading maken.

Met het commando hg clone of hg push kon ik het m’n centrale server krijgen, maar dan bleef m’n lokale repository leading en dat moet natuurlijk andersom. Na een kleine speurtocht ben ik er achter gekomen dat de leading repository wordt bijgehouden in het bestand hgrc (pad is .hg/hgrc). Hier staat een entry in met het pad naar de centrale repository. Door deze aan te passen kun je dus de lokale waarde wijzigen in de centrale.

Enkele weken geleden ben ik begonnen met het ontwikkelen voor applicaties op de Windows Phone 7, zowel prive als op het werk. Vandaag was het dan eindelijk zo ver dat m’n eerste applicatie in de Zune Marketplace is komen te staan.

De applicatie draagt de naam LoveTester en is te vinden op de volgende Zune url: https://social.zune.net/External/LaunchZuneProtocol.aspx?pathuri=navigate%3FphoneAppID%3D50ce8d2e-8af5-df11-9264-00237de2db9e

Binnen Zune ziet het er als volgt uit:

Met de applicatie kan worden berekend hoe goed twee personen (namen) bij elkaar passen. Hier wordt een berekening op losgelaten en een antwoord verstrekt op het scherm. Dit antwoord wordt in zowel een percentage als een korte zin beschreven.

Deze actie kan tot in de oneindigheid worden herhaald, echter wanneer de applicatie nog in trial modus is, zal dit maar eenmaal per dag kunnen worden uitgevoerd. Gelukkig is de applicatie maar 99 cent, dus vallen de kosten ook nog wel mee.

Voor het zien van Windows Phone 7 applicaties binnen Zune dient de locatie van de computer wel te worden gewijzigd in United States.

Hopelijk is dit niet meer nodig wanneer de Marketplace in Nederland beschikbaar is.

Nu maar snel aan de slag met m’n tweede applicatie. Moet nog wel even nadenken wat dat gaat worden.