månadsarkiv: oktober 2013

Debugging OOB SharePoint. Unable to post comments on SharePoint blogs (SP2013 June CU)

I have had a strange bug. The comment text box in a OOB SharePoint 2013 blog doesn’t appear. It only says: “There are no comments for this post.” In this blog post I’ll tell you how I found the bug and I’ll show you how you can temporarily bring the commenting to life.


I have had luck. While it doesn’t work on the Test Environment, it does actually work on my development machine. The comments text box is rendered as an OnPostRender action in the blog comments display template. After debugging the javascript in hours and comparing the two environments, I just could confirm that displaytemplates are the same. There are two main javascript files that are involved:

  • clienttemplates.js
  • sp.ui.blogs.js

So it must some differences elsewhere. The build versions of the environments are

  • Working Environment:  15.0.4420.1017 (SharePoint 2013 RTM)
  • Not-working Environment: 15.0.4517.1005 (SharePoint 2013 June CU)

No errors are thrown, even on the blog where it doesn’t work. It is because of the permissive try-catch in this function that wraps rendering of the comment text box:

This is where the error occurs but doesn’t appear in the script console. Here is the error:

What? jQuery error? Why?

It turns out that jQuery is used to get the html element for the comments area in the server with June CU, but not in the Server with SharePoint 2013 RTM.

To get the reference to the comments area, it invokes the $get method, which invokes Sys.get which in some cases invokes the jQuery (if present)

$get implementation in SP 2013 June CU

These are the functions which can be found in the SharePoint 2013 June CU (15.0.4517.1005)



older (but working) $get implementation in SharePoint 2013 RTM

These are two versions which can be found in the older SharePoint Release: RTM (15.0.4420.1017)

It doesn’t even go to Sys.get and doesn’t even try to use jQuery.

The id of the comment are is a combination of two guids and -CommentContainer. jQuery fails to select an element with this id:
This error happens when you try to select this html element with jQuery in the web console:


Temporary solution

The solution is to prevent using jQuery for this element selection. Hopefully new updates of SharePoint will address this issue. Until then we have to tweak the $get method. To do it very carefully, we can copy the old $get function and call it $get_asFoundInRTM and copy the new $get and call it $get_asFoundInJuneCU

The $get function has to rewritten like that:

This javascript code has to be loaded after two ScriptResource.axd files. Please be very careful if you have to implement this temporary fix. Probably it is better to wait for an official Microsoft bug fix.

Log to ULS using javascript


The more javascript code is produced in SharePoint solutions, the more need we have to log information and possible errors to a central logging  place in SharePoint: ULS. This blog post is about logging to ULS from javascript.

For a while ago I read a blog post:

The author @avishnyakov mentions the ability log to ULS from javascript. I want to dive deeper.

What this function actually does, is that it calls a web service called _vti_bin/diagnostics.asmx

We can follow the function in the init.debug.js

ULSOnError invokes ULSSendExceptionImpl:

ULSSendExceptionImpl invokes ULSSendReport:


An alternative way is to create an own handler that is invoked through an ajax request and that implement an own logic for writing logs to ULS. You can see a neat solution provided by Albert Jan-Shot:

Not to be confused with SP.ULS.log

There is another utility function for logging: SP.ULS.log, this function logs messages in a new browser window. In my opinion, it is a substitute for console.log, but the good thing is that you have to manually enable it in order to see:


Logging from an app

If you are developing a sharepoint app, you can log app errors easily by using:

How to create a massive amount of SharePoint sites in PowerShell

I recently wanted to create a large number of sites on my SharePoint installation and ended up writing a PowerShell script for the job that I thought I’d share. This was for a test for optimization, so I had to have quite a few in order to see some difference between tests.

First you have to find the template that’s going to be used on the sites. This is if you know the template you want to use:

But the template can also be fetched from a current site:

Then create a user that should be the owner of the site:

And then, cause I’m me and hate sites that are named test1, test2, test3 and so on, I made a list of site names:

And then you have to loop through all the names and create sites:

If you are lazy, here’s the script in its entirety.

scriptcs and SharePoint. How SharePoint can benefit?



Last Saturday I attended Leetspeak. Among many awesome speeches and presentations I discovered scriptcs.


scriptcs lets you write C# code directly in the console, or execute scripts written with just your favourite editor. Please see more about it on the site. What I thought during Justin Rusbatch’s session at Leetspeak:

Can we use scriptcs in SharePoint?

Technically there is no limitations in SharePoint for scriptcs. Any .NET code can be registered, imported and invoked in a console or in a standalone script. Here is the simple code for instantiating a site collection and disposing it:

The code above does not do anything, it is just there to demonstrate how you can register the SharePoint assembly (“Microsoft.SharePoint”) and import it into the script:

The example shows even that you in scriptcs no longer need the necessary “boilerplate” (compared to a console application): namespace, Program, Main()… You can just directly write your code.
The rest is the same as in a C# application. The code samples for scriptcs can be any code written in C# for SharePoint, code from custom console applications, from feature receivers, you name it. So my next question is:

How can SharePoint development benefit from scriptcs

I can think about these advantages with scriptcs in SharePoint:

  • Less need of PowerShell. As a developer you can use one language for creating SharePoint solutions and server configurations.
  • You don’t need to rewrite your C# code to PowerShell. It saves time. Often one can see two solutions: one for C#, one for PowerShell, example.
  • You can freely move code from feature receivers to scripts, like timer job installation, without rewriting code, example.
  • You can use scriptcs to discover the SharePoint API, site columns, sites, fields and so on. PowerShell can be used as well. But scriptcs lets you use the same syntax. PowerShell is much different. It is not case sensitive. It often doesn’t throw NullReferenceException, it just doesn’t output anything. So if you use PowerShell as an exploratory tool, then you still will need to verify it in a C# code to verify, that your code works. With scriptcs you can directly copy the code from console directly to your code solution.

Of course, if there are advantages, then it must be some disantvantages.

Shortcomings of scriptcs in SharePoint?

I have found these shortcomings

  • Missing powerful cmdlets for SharePoint (special “shortcuts” for configuration steps of SharePoint like New-SPWeb, Set-SPEnterpriseSearchService…)
  • Missing native functionality in PowerShell for parsing xml, importing and exporting to csv and xml, a very easy way to read and write files on disk.
  • There are already tons of PowerShell scripts written for SharePoint in companies and in the community. Mixing a huge amount of PowerShell with little scriptcs can increase complexity.
  • scriptcs is still new. It is not adopted by Microsoft and maybe will not be approved in your project.

So what do you think about scriptcs and SharePoint?

Would you use scriptcs in your SharePoint project? Leave a comment or send me a tweet.