It’s been some time since my last blog post. This had mostly to do with some personal changes in my life and not really having interesting topics. But since that last post I’ve seen some “error in thinking” that most SP developers did, that I’ve decided to write a blog series about writing code and more importantly, writing code that does the job quicker or better (improving code quality).

Keep in mind that I never criticize the code of other developers, you never know in what mindset the code has been written. Were they on time pressure, lack of knowledge or is it more fundamental and they always write code the same way. Nothing is wrong with that, but as a consultant it is a good nature to question sometimes your own code and asking yourself, can’t this be done faster or is this the correct way?  

Continue reading

A few days ago we had to export and import list items from a certain list, because we used item level security and when your items go beyond 5k item count than you will hit the threshold. Most of the advice that you find on the internet is “increase the threshold”.

Yes you can do that, but ask yourself, why is it 5000? Well this has something to do with the backend of the SharePoint system (which is SQL of course). SQL handles row locks up to a certain amount. More than 5000 and it does a lock on the entire SQL table, which is not good…

So back to our story, we redesigned the structure and used folders instead and see where the security was common. Ok, threshold limit fixed but we still needed to move the items to the folder.

Because we didn’t want to just copy the items and deleting the source item, we used SPExport and SPImport instead. Benefit here is that the entire item is exported, deleted and imported again on the correct location. Very important was the ID, this was a production environment and the mails that already were sent and maybe some lookups pointing to the list. So keeping the ID the same was very important.

Now it didn’t take long before we reached our first error.


After a quick search on the internet we find that when you have custom user fields defined via the elements.xml file like so:

   1: <;Field 

   2: ID='{A77F7435-0F70-44CD-9D4A-C10520E2E0B2}' Description='' 

   3: Name='LoginName' DisplayName='LoginName' StaticName='LoginName' Type='User' 

   4: Group='Meligo'/>

Now the code above will work and all is good in SharePoint land, until you are going to export / import an item.

I wanted to know from where the error comes and after some searching it in a certain area of SharePoint called with reflector we find this:




As you can see a check is being done if the field contains a lookup list and if that lookup list is equal to “UserInfo”. Great this is step 1 in solving the problem.

So some key attributes are missing from the schema. To fix the error above, you need to add in the schema of the field: ‘List=”UserInfo” ‘ .

Next, the export without compression gives you the directory below



In this Directory the “UserGroup.xml” is the one that we should look at. this should contain as many user nodes as there are user fields:


As you can see the “<User” tag is created for each user field in the item, when it is filled in. If it is not filled in, than that userfield is being skipped.

Now we should have 3 user fields here. At the moment this is not the case.

Still, this wasn’t enough. We’ve added the ‘List=”UserInfo”’ to the field schema and pushed the update to all the lists fields. But the user field was still looked at as a Lookup field instead of a user field.

It’s because the field is listed in the manifest.xml but there is no user field correctly parsed to it.

Well it turned out that the ‘mult=”false/true” ‘ needed to be added as well. Only then the field is being considered as an user field.

Good luck hunting for that one Smile

After we did the 2 changes in the field schema the import worked like a charm again.

Also if you get the error / warning “cannot find user with {ID}” than your user isn’t listed in the UserInfo list.

The User Information List can be accessed (Only if you’re admin) via the browser by navigating to /_catalogs/users/simple.aspx from your site. (Ex: http://YourSiteUrl/_catalogs/users/simple.aspx)

Today is the day that SharePoint news will be injected in the MSDN BeLux tweet feed Smile (at least for a week that is).

To quote Maarten Balliauw :

This is the official Twitter account for MSDN BeLux. It’s not hacked, I did not steal the password: they gave it to me!


I would like to thank Microsoft for this opportunity , let me know how I’m doing, hope you’ll like the tweets.

have a nice day Smile

So back in the day when I started working with SharePoint (it was a cold Monday morning Smile ), it was around 2006 – 2007 and WSS 3.0 / MOSS 2007 was just out.

Webparts weren’t commonly known than nor was SharePoint. But we all know that MOSS 2007 was the launch to greater things.

The difference between SP 2003 and 2007 was big, one of the things we needed to ask ourselves was , are we going to inherit from System.Web.UI.WebControls.WebPart (recommended) or from the SP WebPart class..

Some differences between the ASP.NET and pure SP Webpart class:

  • Cross page connections
  • connections between webparts that are outside of a webpart zone
  • Client-Side connections (Web Part Page Services Component)
  • Data caching infrastructure that allows caching in the content database

Also creating a WSP package wasn’t that easy, if you didn’t use WSP builder of CKS than you needed to create your own package..

I think the procedure was (you can read all about it here) :

  1. creating a dwp file for your webpart, with the correct nodes and information
  2. Create a feature file
  3. a manifest.xml file as well
  4. create a DDF file so that you can cab (DDF = Diamond directive file, didn’t even know what it stands for until now)
  5. create a cabinet file using the DDF file (command: makecab /f solution.ddf )

The deployment happened via stsadm Smile 

Those were the times…

Also for MOSS 2007, project server came to the package as well as InfoPath Form services..

Next release of SharePoint was in 2010 and it expanded some more (Office web apps, FAST search server, …) . Webparts could still be created but you can now create also Silverlight packages and use these in SharePoint to make it more beautiful. Silverlight could also be used in MOSS 2007 but you had to write your own wrapper around it and Silverlight could only use the web services or use the OM via the wrapper. But also JQuery came to light (Jquery could also be installed for MOSS 2007, you can read about it part 1 and part 2 in the Blog of Jan Tielens ) but it wasn’t used that much in 2007 than in 2010 I believe.

In SP 2010 REST came into play and also CSOM and an OM especially for Silverlight. So we could already see the step towards client side code more and more. Sandbox helped in that regard as well. All this was created because Webparts are running solely on Server side. Meaning that it could impact the performance of the Web front end machines. So moving the logic client side would be a very logical step.

In SP 2013 we see that the CSOM had been expanded with extra functionality and APPS are doing more and more the work of replacing the sandbox solutions. Also more client side stuff can be used here as well. MVC, JavaScript, JQuery, Silverlight, Knockout, PHP, HTML… you name it, it can all be used in SP 2013 now (some of the technologies could be used in SP 2010 as well).

The reason why I’m writing this blog post is because I’ve highlighted this in a very small part in one of my previous blog posts and after some talks with Karine (Bosch) and some other people of the MEET team. We are all saying the same thing.

It’s no longer sufficient to write only C# code and all server side. Ok it’s the easiest because we’ve grown up with it almost and it’s what we know best. But a SharePoint developer should start to make his/her first reaction, “am I going to write this in a webpart or an app, what is the best technology for this, is it going to be multi lingual”? All these questions should be asked first before writing one line of code. The technologies that are available for us are too diverse.. and you can clearly see the move to client side code.


Some quotes Smile

Einstein and SharePoint are two paths that never crossed – but applying his most famous quotes to SharePoint creates an amazingly rich and accurate framework of discussions that all SharePoint experts should learn from.

Here are some great examples:

“Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.” – Albert Einstein

“If you can’t explain it simply, you don’t understand it well enough.” – Albert Einstein

“Information is not knowledge.” – Albert Einstein

That’s it.. have a great week..


The location for the Codeplex project is here.


After messing around a lot with the elements files to generate some pages I’ve created a small webpart that does all this stuff for you.

I’ve reused some code from this codeplex project and I’ve asked Stefan Stanev if I could re-use it. Also I’ve added some functionality.

The codeplex project of Stefan connects to SharePoint and if you go to the page via de program than you can right click and generate the elements.xml file.

Only the program doesn’t take into account connections between webparts. This and some other small adjustment I’ve added in my solution. So the elements file that you can generate via my webpart should be the most complete one representing the page.

I’ve shared the code with Stefan so that he can update his package, but I don’t know if he did this or not.

So the install is easy, it’s a WSP so install, deploy and put it on an webpart page (example called: admin.aspx).

How does it work? Continue reading


hey everyone

A couple of months to almost a year ago I had to write some documentation and lookup a lot around sandbox solutions. More precise when you would go for sandbox and when to farm solutions.

So I’ve restyled the document a little bit and you can download it as of now…

If there are some things you don’t agree or is incorrect let me know so I can change it…

Since I’m not all for re-inventing the wheel most of the information is a collection of blogs that I’ve found, all the links are saved in references at the bottom of the document.


Sandbox isn’t changed much in SharePoint 2013 so the document can be used for SharePoint 2010 and SharePoint 2013.

hope it helps someone

I’ve released a tool that generates the elements.xml file for you, just create a webpart page and use the tool to extract the module from it… you can find the blog post about the tool here.

So yesterday I had a whole day of fun with the xsltListViewWebpart = XLVWP, this is for SharePoint 2010 in SharePoint 2007 it’s called the listviewwebpart.


Deployment of the module files that contain all kinds of webparts and always 1 or more XLVWP(s) .

But since we’ve added folders to the lists than this isn’t sufficient and we need to add “scope=recursive” to it as well.


  1. XLVWP are not actually “deployable” (hardcoded list ID’s)
  2. The default view is always used, so even if you set it correctly, the architecture of the XLVWP will work against you


This really depends on what you want to do…

Deployment of an XsltListViewWebpart


First things first, check out this post if you don’t know how to provision a webpart to a page.

Ok, now a first issue.. if you want to export a XsltListViewWebpart, you will have to do it via SharePoint Designer, it is not possible to export it via the GUI.


So fire up the old SharePoint Designer, go to the page, and select save web part.


Now you should have a .webpart file that should contain something like this:


After reviewing the entire xml structure you will see 3 things:

  • in the listName it gives a guid (list id)
  • in the webID property a null guid is given
  • in the xmldefinition property the url attribute is being filled in with the server relative url of the list.

So this is not good, the entire xml is too much and uses a listID? Yup, it actually expects to be redeployed with a single change.. Delete the list and recreate the exact same one.. the list id will be changed.. it will not work and give you an error message.


Well happy hunting to what this could be.

you could add ?contents=1 behind the .aspx in the url, than you can see that one webpart is giving issues. 


Now the solution:

There are actually 2 possible solutions:

  • Either create a view tag and put in a minimal xsltlistviewwebpart like the picture below



the view tag is a special one

On one msdn page you can see “The View element specifies list view Web Parts to use on site pages. “. So the purpose is to view lists.

but if you click on the view tag hyperlink you can read “Describes a view within a module for a site definition.”.

mmmm, so no listviewwebpart stuff? Glimlach

But you can define some other properties as well, like scope, rowlimit,…

  • the second solution to minimize the properties being given with the xsltlistviewwebpart


Note the property name, ListUrl…

do not put an “/” in front of Lists, this will create an issue with the webpart that it cannot find the list.

Be careful when deploying the page more than 1 time, the webparts are just being added without rendering a new webpart ID. This will result in an error message saying that the webpart with the ID already exists. Best practice is to completely remove the pages and recreate them again via the elements file. Of course all changes made to the page in the meanwhile will be lost than.

Download the demo solution: icon_home_skydrive

I’ve created a codeplex solution for the generation of the webpart pages into a module (elements.xml) file. you can find it here

Some resources:

And a teaser for one of the next blog posts… Glimlach

In the last resource link a sentence stands out in the blog:

The short story of a lot of tries is: it does not work. Yes you can change the XmlDefinition property, but the XsltListViewWebPart does not use it after you have changed it.

Today I noticed a good tool that you can use to create your own module elements files including extraction of the aspx file and automatic creation of the feature file as well.

This tool is created by Stefan stanev and can be found here.

But as I was using this I noticed that Views and Connections of connected webparts are not being extracted. So I’ve mailed Stefan and asked him if I could re-use some of his code and added some extra code so that the webpart connections are included.

The reason why I’m releasing this in a codeplex project as a webpart is because I believe that this could come in very handy for us SP developers. No longer creating the module elements file via code. Just click together what you want on a page and extract the module.

The codeplex project can be found here. Some styling still needs to be done.

First I’ve created a sandboxed solution, but this wasn’t possible because I use the SPLimitedWebPartManager . And as you can see, this is not usable in a sandboxed solution.

Ok, let’s start by explaining the module element.

In the elements file you can define multiple <Module> elements, all the possible attributes are listed below:

  1. includeFolders: (optional,string) – actually couldn’t find a single document/blog/page that describes what this attribute is for…

Karine (Bosch) found the answer:

Apparently when you have some files in your module element that need to be put in a subfolder of the library you use this attribute..

So you define includeFolders as ??-??

<Module Name=”PublishingLayoutsPreviewImages” Url=”_catalogs/masterpage” IncludeFolders=”??-??” Path=”” RootWebOnly=”TRUE”>
<File Url=”BlackVertical.png” Name=”Preview Images/BlackVertical.png” Type=”GhostableInLibrary”>

But this didn’t actually work for me.. so use at own risk Glimlach . Don’t really think you’ll ever need this.

Also somebody noted that it add the files to all child folders.. but this I don’t believe to be the behavior.

I’ll try to find it out in code how this part behaves, will get back to this one.

  1. HyperlinkBaseUrl: (optional,string) – This specifies the absolute url to be the base url of the hyperlinks… while I have set this and deployed to other sites (different from the base url) everything still worked, so really didn’t find any real value in this attribute
  2. List: (optional, integer) – Type of list where the files included in this module should be provisioned.

Let’s go to the onet.xml file where we can find an example on this one. As you can see the master page gallery has an typeId of 116. In the module node there is a defaultmasterpage example that has list defined to 116. So the defaultmasterpage is being deployed to this library.


  1. Name: (required, string) – contains the name of the file set. Nothing really special here.. just provide a name


  1. Path: (optional,string) – specifies the physical path of where the files are in the features folder. By default SharePoint expects the files to be in the same folder as the feature file. But you can also define the path attribute per file node
  2. RootWebOnly: (optional, boolean) – set to false by default, if you are installing the module only in the top level web site of the site collection than you must set this to true
  3. SetupPath: (optional,string) – specifies the physical path to a folder in the 14 hivetemplate that contains a file to include in the module.

Let’s say that you want viewpage.aspx in the pages directory under the template directory than your attribute should look like


  1. Url: (optional,string) – Specifies the virtual path of the folder in which to place the files of the module. This attribute is also used to provision a folder inside a list. If the Path is not specified, the value of this attribute will be used for the physical path also.