Archive for SharePoint

Microsoft Ignite key takeaways

Great Content, Great Vibe; Ignite is here to stay

The first thing I learned from Ignite is that it wasn’t a mistake to attend to this conference. What a vibe! It’s always good to be around people with same interests and passion when it comes to technology. At first I was a bit skeptic about the integration of different Microsoft events but it turned out to be a success. The high quality sessions, well organized location (WiFi still kinda sucked but let’s call that a tradition) and for the first time I felt the Expo hall was actually a great addition to the conference. Normally this is just a platform for vendors but this time Microsoft had the biggest stands which were really good. People from the product teams where walking around every day to give information and support on a level I hadn’t experienced before. Awesome! So what are the key takeaways for me as a SharePoint / Office developer?


Self-contained Applications Cross Platform using ASP.NET

During the conference it was made clear that to drive productivity to the next level, the experience Microsoft offers should not be bound to a particular brand of device or even Operating System. This is a very bold statement if you ask me. The verge wrote an excellent article comparing its vision to Apples vision on this matter:

A big help in getting to that experience are Self-contained Applications. We know this principle from Java for quite some time now. Basically Self-contained Applications include their own runtime and are built in a way that they’re deployable to any kind of platform. For instance using NodeJS for server operations and using AngularJS to build a Single Page Application you can create a package that is deployable to every platform that runs NodeJS. On top of that the entire application model (server – client) is written in 1 common (cross platform) language: JavaScript. These are non-Microsoft technologies but are advertised by Microsoft to leverage the new API’s Microsoft is offering in Office 365. The Office Dev team even supported this by handing out Raspberry Pi’s to stimulate development for Office on different platforms.

Finally Microsoft adopts this principle with the new ASP.NET 5. The DNX (.NET Execution Runtime) is open source now that can be found on GitHub ( and can run on any kind of platform. Given this fact we don’t have to run an ASP.NET MVC Application on an IIS server but we can use a Linux based server with the ASP.NET 5 runtime! Making the runtime open source gives a lot of insight in the .NET platform and is a huge leap forward for Microsoft. See a great session from Glen Condron here:


Office 365 as Data Hub (ePaas)

Is SharePoint going away? Expected is that the brand name “SharePoint” is fading but the SharePoint technology is very much alive. It is the very foundation of the Next Gen Portals in Office 365. These portals are offering a way better experience for End Users but also from a developers perspective this is a huge improvement. For a while now Microsoft is unifying its API for Office 365 into one endpoint. With this endpoint developers can get all the data out of Office 365 they want. There was an example in a developer session where Rob Howard rebuilt the Video Portal by just using the Unified API in his own app running on NodeJS. In this case Office 365 is used as a Data Hub and not as a platform where we try to customize the OOB experience. When a different experience is required, we can now built it ourselves by leveraging the API. Andrew Connell describes this as ePaaS (Enterprise Platform as a Service) in this excellent post:


SharePoint 2016

Remember the SharePoint Conference in 2012? In my opinion this was quite a confusing one. Microsoft just bought Yammer and was hinting towards the Cloud first approach for SharePoint Online thereby leaving the development on the On-premises version a little bit in the open. There was a lot of speculation on if SharePoint would made it to a next On-Premises version or not. In 2014 it became clear that SharePoint 2016 will be the successor of SharePoint 2013 On-premises.

Now at Ignite, Bill Baer announced what SP2016 is going to offer us On-premises and a little hint (again) on the future. “SharePoint 2013 will be the Foundation of every future SharePoint version.” he said in a session full of SharePoint 2016 intell! Wait, does that mean we can expect a SharePoint vNext On-premises after 2016? That wasn’t confirmed but wasn’t denied either. The vision on this I think is to bring SharePoint On-premises and SharePoint Online more and more together and fade the boundaries between the two. The Hybrid scenario for instance now is part of the SharePoint Products configuration wizard with the Scenario picker. This will make it way easier for admins to configure a hybrid scenario between SharePoint On-Premises and Office 365.

Microsoft has done some outstanding work under the hood to make SharePoint 2016 “Cloud-like”. For instance they’re introducing zero-downtime patching (just like Office 365), a new server role called minRole (minimal server role to scale up fast) and again a stretch of the limits and boundaries.

On a telemetry perspective, SharePoint 2016 will introduce a complete new experience to monitor real-time usage data of the entire SharePoint Farm. Think Google Analytics interface with lots of graphs for indication. Things that are monitored for instance are 404 responses, browser / device info and latency statistics between client, server and SQL.


We need windows 10!

This was already a big factor in the Keynote. Windows 10 will give us a whole new level of user experience. With Cortana integrated in and a lot of new compliance and security features all indicates this will be the biggest release of the Windows operating system to date. A couple of features can be found here:

Cross Device experience will be elevated to the next level with Continuum! This Experience will bring mobile devices and desktop / laptop devices even closer together. This can finally leverage the mobile devices to a “work machine” instead of a “reading machine” when connecting to an external display.

From a developer perspective the thing I liked most is that Microsoft is coming with a Windows 10 Nano version that can be run from a SD card for instance on a Raspberry Pi. This move clearly indicates Microsoft is betting on the IoT (Internet of Things) world to use Windows 10 as a platform for this. There is already a preview available as part of the Windows 10 Insider program:

More of the new key Windows 10 features:



It was great to (re)connect to all my SharePoint friends worldwide and see a lot of excellent content, sessions and labs. Ignite was a great event for me and I hope to return next year! Here a some links to other sessions I saw that I think were very good.

Deep Dive into Safe SharePoint Branding in Office 365 Using Repeatable Patterns and Practices

Building Business Apps Like They Do in the Valley with AngularJS, Node.js, and More

Transforming Your SharePoint Full Trust Code to the Office App Model

MVP Panel: Sample Apps and Intelligent Solutions Showcasing Office Graph and Delve Extensibility

Developing Web and Cross Platform Mobile Apps with Azure Active Directory

Dealing with Application Lifecycle Management in Microsoft Office 365 App Development

Custom MasterPages and SharePoint Hosted Apps

We all know that Microsoft is moving away from the concept of Custom Masterpages (at least on Office 365). Chris O’Brien explains some considerations in this great blogpost–thoughts.html. But say you already have this On Premises SharePoint 2013 Intranet with a nice custom MasterPage in place on a Publishing Site. When you have subsites and especially Team Sites, there is this scenario, when setting the MasterPage, you want to force the MasterPage on all subsites.

Inheritance of the MasterPage

When you stick to Publishing Sites, a new subsite will always inherit the MasterPage from its RootWeb by default. However when mixing publishing sites with a Team Site for instance, things get tricky. Because the publishing Web Feature is not activated on a Team Site, no MasterPage is inherited.



I also deployed a SharePoint Hosted App to the Root Web. Just an Hello World App to illustrate this issue.


If you activate the Publishing Web feature on the Team Site, inheritance is immediately restored. Unfortunately there is another, more harmful, way to force the MasterPage. If you go to Site-settings > MasterPage on the Root Web you can check the box “Reset all subsites to inherit this site master page setting”.


By doing this you can force the MasterPage upon all the subsites in this sitecollection. Because our subsite is a Team Site we need to set the System MasterPage as well. When I select my custom MasterPage at first sight nothing happens and everything is OK. (I only changed the SharePoint brand in the top left Suitebar into a custom text).


Oops! My Apps broke down

After I reset the MasterPage to all subsites when I open up my SharePoint Hosted App, suddenly this error appears (CustomErrors are off).


This error instantly tells us what’s wrong. By resetting the MasterPage to ALL subsites, the App Webs are updated as well, therefore introducing a reference issue because the MasterPage is now linked to the Host Web’s MasterPage instead of app.master on it’s own App Web.

Powershell to the rescue

The easiest solution is to remove the App and add it again to the site but in most cases this don’t want to do this. Especially when there is data in the App Web. Using powershell to repair the MasterUrl is the obvious solution here. The code I provide here is based on an On Premises environment. When using Office 365 you will have to write some additional code to make the connection.

Famous last words

This error occurs only in this very specific scenario and if the reset is applied for the System Master Page. When you reset all sites to use the Custom Master Page all apps will keep working. In my experience this specific scenario occurs when mixing up Publishing Sites with Team Sites. Because Team Sites don’t inherit and you can’t set a Team Sites MasterPage from the Site Settings.

Hide empty fields on a SharePoint 2013 Page Layout

Nice this is already my second post this month, that doesn’t happen often! This time a little trick to help developers with Custom Page Layouts. I’ve seen quite a few solutions where Custom Page Layouts where used to display content in a sort of Form feel. For instance where all the Content Type fields are rendered with Labels to indicate what the content means. A typical problem with this solution is that whenever you decide to leave the contents of a field empty, still the Label is being rendered. And so is the HTML of the field.

Custom Controls

When searching for a solution lots of BlogPosts pop up about creating a custom ASP control based on the SPSecurityTrimmedControl to manage the rendering like in this Post of Brian Farnhill.

This approach works in an On-Premises environment where moving to the cloud is not an issue. But since I’m a huge fan of Cloud Ready programming I was searching for a different solution.

jQuery for the win

The first open door is to use jQuery on the page for some good ol’ DOM manipulation to make the fields disappear when empty. We can easily work our way through the DOM looking for elements to hide. This is an ok solution but I prefer to have it a little bit more generic. Besides that I took some time to investigate in other Frameworks over jQuery and came across this post:

In short: Libraries and FrameWorks are two different things used for different purposes. Since I’m a fan of data-binding and the abstraction level a framework provides, I decided to use Angular.

Angular for the win

When using Angular this issue can be solved in many ways. I choose to create a controller and applied it to a <div> element that wraps the SharePoint Control that needs hiding. My Page Layouts is looking like this.

Here we have the Display of the Titel Property and a Field calld “DoelGroep” which is a TaxonomyField. Preceding the contents of the Taxonomy field is a label Displaying the DisplayName of the Field.

Wrap the Field

First I have to add the data-ng-app to the top element where all the fields are childs of.
<div class="article-content row" data-ng-app="Empty">

To make sure my Controller works on the specific Fields, I have to wrap those fields with a new HTML element.
<div data-ng-controller="EmptyController"></div>

How my HTML finally looks.

Build the Controller

Now all we have to do is write out the controller. Since we are only wrapping the SharePoint Field that holds content we have to keep in mind to remove its parent since the Label is part of the parent as well.

Edit Mode

Since we don’t want this javascript code to execute when the page is in Edit Mode, we need to add this piece of script to a EditModePanel with DisplayProperties set to View.

That’s it

Just by applying these small changes to the Page Layout (of course make sure AngularJS is loaded). Pretty awesome and practically works with most SP Fields (I haven’t checked them all). Hopefully this will help build a solid solution to deal with empty SharePoint Fields on Page Layouts and is a “cloud ready” solution.

4 Steps to smarter App Part resizing

Wow it feels like forever since I wrote something and finally I got some good new content. I started to research a little bit more on the resizing of App Parts in SharePoint Hosted Apps and came up with some really small changes in basic CSS and JS that make App Part resizing a lot more stable and X-browser compatible. #winning


1. No horizontal scrolling

In this example I’ll use an App that Lists Apps on the Host Web. This particular App displays a list of Title just below one another. Nothing fancy. However when we want to display the page in an App Part, this happens.


Visually it seems that we have more then enough space between the Titles and the end of the IFrame (300px width by default). Still we see a nasty scrollbar! What happened? Inspecting some elements up in the DOM explains a lot. Very funny SharePoint.


The defaultcss.ashx causes trouble! This control is loaded on the page by default in an ASPX page like Default.aspx or most likely by a dev in a plain HTML page to keep default SharePoint branding alive in the App. That is a good principle, but this width style is not really helping us out.

Full Width Power

In order to get rid of the scrollbars in this scenario there’s a simple CSS fix we can apply in our App.css.

#contentBox { min-width:100%; margin:0; }
#contentRow { padding:0; }

This way we make sure no weird margins or paddings will cause our App Part more pain and it’s also going to help us when resizing the WebParts height later on.


Better! Now the content, that we know for sure should fit, actually fits. Width wise. Still the height of the App Part is not right.


2. Resize your App Part

Resizing App Parts using the postMessage technique is nothing new to most people. We need a function in our App that sends a message to the parent of the IFrame. SharePoint can pickup this message and then resizes the IFrame for you using a given width and height. I used the following code

resizeIFrame = function (height, width) {
 if (window.parent == null) return;
 var senderId = '';
 var params = document.URL.split("?")[1].split("&amp;");
 for (var i = 0; i &lt; params.length; i = i + 1) {
  var param = params[i].split("=");
  if (param[0].toLowerCase() == "senderid")
   senderId = decodeURIComponent(param[1]);

 //Bug for self reference in href='#'.
 senderId = senderId.replace('#', '');
 var message = "<Message senderId=" + senderId + ">"
 + "resize(" + width + "," + height + ")</Message>";
 window.parent.postMessage(message, "*");

In this common piece of code I added a check for “#”. When this is used in the App (I came cross it once), the QueryString is extended with this “#”. This causes the SenderId, which is always last in the QueryString, to be compromised and the Resize function from SharePoint to fail!

Function call

To call this function we first determine the height of the DOM element that holds all the content. The width shall be “100%” to have an App Part that will always fill the entire space.

var height = jQuery('#OverView').outerHeight(true);
var width = "100%";
resizeIFrame(height, width);

This function resizes the entire iframe to the dimensions given.


But wait! there is still a vertical scrollbar! Something must be wrong. In the Elements File of my ClientWebPart I removed the Height and Width properties of the App Part.


Here is where a very weird phenomenon shows itself. Since we don’t have any requirements set regarding width or height, SharePoint sets a default width and height to the AppPart which is the same as the ClientWebPart xml states when it is just created.


Here our default width is 300px. The funny bit is that because we use the ResizeIFrame method, the width is only set to 100% after the Resizing is done. To make it even more complex, the Height is meisuring the content that now is rendered within 300px width. Therefor the height also cannot be trusted. This makes the resizing of the App very buggy. Now we see it still as 300px width. Refreshing a couple of times shows 100% width but still with a vertical scrollbar and height that is just a couple of px off. Some DOM element must be holding back some padding info.


3. Body Container

Again the main obstacle here is some styling that comes from defaultcss.ashx. By default the CSS sets a padding-bottom:35px; on #s4-bodyContainer. This is why we add to our App.css this piece as well.

#s4-bodyContainer { padding:0; }


Instantly this is starting to look good! The App Part now scales over the entire width of the Page using a correct height and most important: NO scrollbars! Since I placed my App Part in the text part of this SitePage it is displayed in full width. When I use a Publishing page with multicolon WebPart Zones, it will also adept to the width of the colons. This comes in very handy for instance with use of Bootstrap.


4. One last thing

One last nag, which is actually really tough. Thereby I don’t mean the fix, that ones easy. I’m talking about consideration on how to deploy the fix. The thing is, as I just explained, the height is calculated at the wrong time in rendering. In order to get the height right, the IFrame must have it’s width set to 100% first. We’ve seen SharePoint set it to a default value of 300px. When a dynamic list of <span>’s wrap over 3 lines for instance, the height at a 100% width is very different from the height at 300px width.

A fix here can be set all IFrames to a default width of 100%. I don’t see why you shouldn’t do that in the first place. But still it depends right.

Custom CSS

The best option in my opinion is to use the capability to upload and add your custom CSS when using Publishing Sites. You can do this in the MasterPage section of the Site Settings. Just create a blank CSS file and add

iframe{ width:100%; }

When you aren’t using publishing sites, there is another possibility.


You can add some code to your App to deploy a UserCustomAction to the HostWeb. In the UCA you can add a ScriptBlock that writes this CSS style to every page. This is a dangerous option when not done right. Waldek wrote about these things and explained why it can break your site. The following code will do so, but keep in mind that everytime this executes another UCA is created. You still have to create a “Run Once” type of mechanism.

P42.ScalingAppPart.setFrameWidth = function ($) {
 var execute = function () {
  var deferred = $.Deferred();
  var hostUrl = decodeURIComponent(P42.Utils.getQueryStringProperty("SPHostUrl"));
  var appWebUrl = decodeURIComponent(P42.Utils.getQueryStringProperty("SPAppWebUrl"))

  var context = new SP.ClientContext(appWebUrl);
  var factory = new SP.ProxyWebRequestExecutorFactory(appWebUrl);
  var appContextSite = new SP.AppContextSite(context, hostUrl);
  var site = appContextSite.get_site().get_rootWeb();
  var userCA = site.get_userCustomActions();

  var customAction = userCA.add();

  context.executeQueryAsync(function () {
  }, function (sender, args) {
   deferred.reject(sender, args);

  return deferred.promise();

 return {
  execute: execute

Famous Last Words

These steps will get you some smoother App Part resizing experience that will work cross-browser. By removing all the extra margins and paddings you are now in control over the exact width and height of your App Part. I never got it right untill I put some work in it, hopefully this post will help you too getting it right.

– Cas

SharePoint Hosted Apps: Targets and Debugging

UPDATE: After I got a nice email from the Office Tools Dev Team I installed Update 2 for Visual Studio 2013. This Update provides a choice of Deployment Target in the Project Properties window (not the pane). On the SharePoint Tab you’re now able to switch between SharePoint 2013 and SharePoint Online. This changes the Target Version and solves the error.


Original Post

Today I came across a strange issue when deploying and testing SharePoint Hosted Apps from Visual Studio. When you create a SharePoint Hosted App in VS, you need to specify a debug target for the App in this dialog:


In this Example I choose to deploy it to my Office 365 Developer site. Deploying and testing this App on my Developer site works perfectly but things go sideways when I change the Deployment Target to my On-Prem server. When I hit Deploy I instantly get the error:

Unknown SharePoint version: 16.0, Parameter name: version


Deployment Targets and versioning

The cause of this nasty error is the dialog above where we specify our debug site. For some reason Visual Studio thinks we are never gonna change it after this point. Therefore the TargetOfficeVersion property in the project file is set to the first target of choice. In my case this was my Office 365 Developer Site which is already running on version 16.0. I can easily check this by opening my .csproj file.


When I create a new App and set my debug site to my On-Prem environment the number in the TargetOfficeVersion property is 15.0. Unfortunately this is something I wasn’t able to find through the Visual Studio UI in project settings or properties.


If you start developing with a Cloud First approach (which I think is the way to go) you might get into trouble testing On-Prem depending on the versioning and updates on Office365. Therefore keep in mind the rapid update cycle on Office 365 and the difference with your On-Prem environment.