There are 2 ‘features’ in SharePoint (MOSS2007) which have kept me busy for quite some time in my last project. Yes, you’ve read it right the first time, my latest project was a MOSS 2007 web portal. Of course these issues aren’t really quirks as the product behaves by design, but it has kept me busy for more time as I would bargain for.

First quirk

For some reason I had to create a console application to query the SharePoint user list and delete the users. Normally this doesn’t pose a problem at all. However, this time the following error was thrown every time:

The Web application at https://your-website-here:80 could not be found.
Verify that you have typed the URL correctly.
If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.

Quite strange, as the website does exist, I even double checked it.

After doing some research on the matter it turns out you need to specify the Platform target for your application. Mine was set to Any CPU and had to be changed to x86. After changing this specific option the code was running correct.

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.

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.

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.

Het standard menu van Sharepoint 2010 is op zich prima voor interne sites, echter bij een publieke website wil je hier wel het een en ander aan styling toepassen. Het standaard menu uit Sharepoint 2007 is gelukkig helemaal verbeterd en is tegenwoordig een stuk beter te stylen.

Het menu wordt gedefinieerd als een SharePoint:AspMenu. Dit is eigenlijk gewoon een asp:AspMenu met enkele uitbreidingen voor Sharepoint. Je kunt hier zelf niet van overerven, aangezien het een sealed class is. Er zijn her en der wel oplossingen te vinden waar men uiteindelijk toch in staat is geweest om de code van het menu over te erven. Wanneer er alleen wat gestyled moet worden is dat niet direct nodig, hoewel ik denk dat het toch wel handig kan zijn.

Omdat je eigenlijk werkt met een asp:AspMenu, kun je dus ook je eigen templates maken. Van onze designer had ik de opdracht gekregen dat het menu als hieronder moest worden gerenderd:

<ul class="">
	<li class="selected_menu_item"><a href="/default.aspx">home</a>
	<li class="selected_menu_item"><a href="/Pagina/zwanger.aspx">zwanger</a>
	<li class="selected_menu_item"><a href="/Pagina/baby.aspx">baby</a>
	<li class="selected_menu_item"><a href="/Pagina/peuter.aspx">peuter</a>
	<li class="selected_menu_item"><a href="/Pagina/schoolgaand_kind.aspx">schoolgaand kind</a>
	<li class="selected_menu_item"><a href="/Pagina/puber.aspx">puber</a>
	<li class="selected_menu_item"><a href="/Pagina/jong_volwassene.aspx">jong volwassene</a>
</ul>

Tijdens m’n ASP.NET tijd had ik al geleerd dat je in het asp:AspMenu gebruik kunt maken van het ItemTemplate blok. Het enige dat ik hoefde te doen is de header en footer (de UL-elementen) boven en onder het menu te plaatsen. Uiteindelijk is er deze code uit gekomen:

In Sharepoint 2010 is de handige ribbon aanwezig om acties te kunnen voltooien op de website. Voor de publieke website die ik momenteel aan het ontwikkelen ben is het niet nodig dat anonieme gebruikers deze ribbon krijgen te zien. Het past immers niet echt in de stijl van de website, anonieme gebruikers kunnen er niets mee, waardoor het alleen maar afleidt.

Gelukkig is er tegenwoordig een oplossing voor die out of the box kan worden gebruikt, namelijk het volgende stukje code:

<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="ManageLists">
    Put	Your Control Here
<SharePoint:SPSecurityTrimmedControl>

Uiteraard kan deze code voor veel meer dingen worden gebruikt dan alleen de ribbon. Zoals altijd, gebruik dit met mate!

Mogelijke waarden die kunnen worden gebruikt bij het attribuut Permissions zijn te vinden op deze MSDN pagina.

Voor de volledigheid, hier ook het overzicht dat momenteel op de pagina staat:

In Sharepoint 2010 is het nu mogelijk om gebruik te maken van webtemplates. Zoals ik het zie is dit een evolutie van een Site template en een site definitie, maar er zijn genoeg anderen die hier een betere uitleg over kunnen geven, Mirjam geeft hier bijvoorbeeld een goede uitleg over: Post 1 & Post 2.

Omdat het gebruik van een webtemplate wel heel handig lijkt, heb ik dan ook besloten om dit te gebruiken voor het provisionen van m’n Sharepoint 2010 website(s).

Het kan kan gewoon door het plaatsen van een leeg element binnen je solution en deze in een feature te plaatsen. Dit ga ik hier niet beschrijven, omdat er al andere blogs zijn die dit goed hebben gedaan, zie bijvoorbeeld Stefan Stanev’s blog.

Komt er eigenlijk gewoon op neer dat je een nieuw element maakt en hier een onet.xml in plaatst en de bijbehorende bestanden:

Let hier wel op dat met een webtemplate geen modules kunnen worden ge-provisioned. Het is dus waarschijnlijk verstandig om de default.aspx te verwijderen en de onet.xml aan te passen dat de modules niet meer worden gebruikt.

De opmaak van het Elements.xml kan wel uit een van de eerdere gelinkte posts worden gehaald.

Na activatie van de wsp zullen alle features binnen de solution worden geactiveerd binnen de site collectie (heb als target de Site genomen). Een prima manier om je webtemplate uit te rollen en daarom ging ik ook verder met de bouw.

Ik heb enkele features gemaakt welke worden geactiveerd bij het aanmaken van een nieuwe site. Voor de zekerheid controleer ik hier of de aangemaakte website wel van het type PublishingWeb is, dit kan gelukkig heel eenvoudig met PublishingWeb.IsPublishingWeb.

Nu had ik de code in debug redelijk goed doorgelopen en werkte alles ook naar behoren. Tijdens het testen liep ik echter tegen wat vreemde problemen aan. De subsites werden maar half gevuld. Omdat ik hier tijdens het debuggen nooit last van had gehad vond ik dat nogal vreemd. Gelukkig wordt er in m’n feature redelijk wat gelogd, dus kon het probleem snel worden gevonden. Blijkbaar waren de aangemaakte sites niet een PublishingWeb. Omdat ik er zeker van ben dat dit wel het geval is, moest het dus wel een ander probleem zijn. Gelukkig ben ik niet de enige die hier last van heeft gehad en zijn er menige posts te vinden waar dit probleem in wordt beschreven.

Het komt er op neer dat na het aanmaken van een nieuwe PublishingWeb er op de achtergrond nog het een en ander gebeurd en er op een timerjob moet worden gewacht voordat de nieuwe PublishingWeb ook goed kan worden herkend.

Dit is ook de reden waarom de methode wel goed werkt in een while-loop, omdat je daar in kunt blijven totdat je eindelijk een true terug krijgt. In een productie web-omgeving lijkt me dat niet echt een ideale situatie en zou ik het gebruik van een dergelijke while-loop constructie ook afraden.
Het is in ieder geval iets om rekening mee te houden wanneer je een Sharepoint 2010 website aan het provisionen bent.

Tussen de opdrachten door ben ik bezig het provisioning proces van een Sharepoint 2010 public facing website te automatiseren. Een van de onderdelen die hier bij hoort is het plaatsen van de verschillende webparts op de pagina’s.

Tijdens het plaatsen van de custom CQWP’s kwam ik er achter dat dit niet allemaal zo goed werkte. De webparts werden namelijk niet geplaatst en ik kon niet direct uitvinden waarom dit het geval was. Na een zoektocht kwam ik op het weblog van Waldek uit waar hij een mogelijke oplossing voor het probleem heeft, zie: https://blog.mastykarz.nl/inconvenient-provisioning-content-query-web-part-instances/. Hij heeft namelijk ook problemen gehad met het plaatsen van een CQWP op een pagina. Volgens hem komt het probleem voort uit het feit dat de HttpContext eerst leeg moet worden gevuld met informatie van de huidige gebruiker:

It turns out that each time you instantiate’SPSite’the SharePoint Object Model reuses the context information if available. And if the context information you provided doesn’t contain any information on the current user, the created reference will be as it was called by an anonymous user! The HttpContext.Current property is static so it will remain available during the whole deployment process unless you explicitly clear it. Back in June I provided you the following code snippet to imitate the context data:

Read more →

Gisteren heb ik voor het eerst sinds tijden weer een Sharepoint 2010 omgeving in elkaar gezet. Vorige keer dat ik dat had gedaan was toen Beta 2 net uit was. Ook toen liep ik al tegen een probleem aan, namelijk dat ik geen nieuwe web applicaties kon maken. Op dat moment was ik er maar van uit gegaan dat het kwam omdat het nog een beta product was of iets dergelijks.

Het lukte me gisteren nog steeds niet. Het icoon New was disabled, waardoor ik niet een nieuwe web applicatie kon maken.

Verschillende resources op internet schreven dat de DisableLoopbackCheck fix kon helpen, Internet Explorer met administrator privileges moet worden opgestart, etc. Al die dingen had ik al gedaan. Wanneer je Central Administration opstart krijg je namelijk automatisch al de UAC naar voren.

Uiteindelijk heb ik maar de UAC uitgeschakeld en opnieuw opgestart. Resultaat is dat de New knop nu wel ge-enabled is.

Beetje jammer dat je voor een Microsoft product de UAC uit moet schakelen om het goed te laten functioneren.