Archive for Cas van Iersel

Getting normal link behavior to your App Parts

Lately I’ve been working a lot with App Parts for a customer. The one thing that bothered me most was the behavior of links as a result of the iFrame an App is rendered in. I’ve come up with 2 solid solutions for the links in an App Part to behave like all other links without having to worry about the iFrame.


My goal is to keep the default behavior of an <a> element intact. In the browser that means that we should still be able to open up a menu with the right click, but also support a ctrl + click to open the link in a new window. By default when you click a link the page should not be opened in the iFrame but in its parent window instead.

jQuery for the win

Since jQuery is added to your App via NuGet by default (at least for SharePoint Hosted Apps) this was the most obvious Library to fix the problem with. In this example I’ll build a simple SharePoint Hosted App with very little code. First my HTML part:

Since jQuery is a library for DOM modification we need to write a script that modifies the <a> element after it is rendered. We need an action on document ready and a function to iterate all <a> elements. Here’s my code:

Alright so this works, but as you might know I’m very fond of frameworks and especially Angular JS.

AngularJS for the win

In my opinion Angular gives us the best solution since the framework works with databinding and not DOM manipulation which basically means that all the modifications are in place once the page is loaded. No need to iterate the DOM afterwards. First the HTML:

In this solution we create a custom directive. That means that all HTML elements that have this directive (in this case just the <a> element as a directive) will have this same behavior.

Hopefully this will make the life of an App Part developer a lot easier!

Originally posted on:

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.

My Key Takeaways from #SPC14

WOW is the first word that comes to mind when I’m thinking of the week I have had in Las Vegas during the SharePoint Conference 2014. IT. WAS. AWESOME. It’s also cool to see lots people felt the same way. The hashtag #spc14 was on fire! But still for the people that couldn’t go, I want to point out some new Key Concepts that are going to rock our Dev World!

Office Graph

Something we could have been expecting since MS bought Yammer is a Graph protocol that works with SharePoint, Office and Yammer objects. Yammer was already based on Open Graph (like Facebook is) and therefor it’s no surprise Microsoft has been working on this to cover the entire Office space. In the Keynote the Office Graph was anounced with a demo on Project Oslo. A new, personalized and highly interactive App based on this Office Graph principle. It really looks awesome and the Graph will also be part of a new API in Office! Learn more about this right here:

Unified API’s

With the addition of Office Graph and lots of other new Features, the API’s for Office (I’m including SharePoint as a part of Office) are starting to change. A thin red line that was to discover in the Development tracks this SPC is that Microsoft is unifying the API’s that Office 365 (including SharePoint) have to offer. By that I mean that Microsoft is clearly pushing 1 technique and that is by using REST and OData. Microsoft is heading for a model where every API is a RESTful service, wheter it is an Office API or a SharePoint API. Now this is a big deal! The vision here is that those API’s will be Entity Driven. When asking the API for files they will most likely come from SharePoint or OneDrive. When asking for contacts, they will come from Office. The Office / SharePoint team is now even talking to the Dynamics CRM guys and the goal is to achieve the same for Dynamics CRM Online. That would be sweet!

Examples of the new Office API’s and a list of new Features can be found here:

The App Model

It may be clear to most of you that considering the API “Unification”, the App Model is still the way to go and is heading for adulthood! Good to hear the Product Team is hoping to get AutoHosted Apps out of Preview by the end of this year. This will be a nice addition to the App Store across the Globe. There already is a roadmap for the localization of the store for the next wave which will be somewhere Q2 of this year. The Netherlands is one of those first countries the App store will become available to.

In combination with the new Office API’s it is way easier to build Office Apps now. Microsoft rebranded these to “Contextual Apps” by the way. On top of this all, Microsoft has released an Open Source Android SDK to build Apps for Android devices. Didn’t see that one coming! You can get it here from GitHub:

Another thing that really surprised me was the presence of Google in the App Development tracks. One of my favorite frameworks Angular JS was used quite a lot in App Demo’s. Microsoft is not afraid anymore of Frameworks not build by Microsoft and the MVP’s are really promoting these new JavaScript Frameworks (Angular, KnockOut, Breeze).

Microsoft is opening up

Finally something that I think is the most important thing during these conferences. You can get a good idea of where Microsoft as a company is heading. My overal feeling with Microsoft this conference was that Microsoft is really opening up to it’s partners. Never was I so close to the people that actually built SharePoint and Office 365. As one of the Nordic Partners we had the opportunity to sit down with the productteam and ask questions about the present and future of SharePoint and Office 365.

Besides organizing these kinds of roundtables, it was clear that Microsoft is really happy with the Feedback they receive from everyone in the SharePoint community. There is a User Voice site to submit feedback from a developers perspective. And also Stack Exchange is an official channel used by Microsoft.

It was also good to hear that Microsoft is working on plans to re-introduce the Technology Adoption Program (TAP) for Cloud models. This would be a very welcome feature so Partners and Developers can test the new API’s, Features etc that will be released in Office 365 later on. Unfortunately Microsoft is still working on this idea and so my guess is that we will have to wait a little longer before this will come around. Lot’s of uncertainties here, but the important point here is that Microsoft is sharing more and more to it’s partners and developers. Go Microsoft!

Famous last words

When I compare this conference to the one in 2012 I can clearly see Microsoft has started listening to our feedback and they’ve done a great job on this conference. The sessions and speakers where top notch in my experience and everything was very well organized. Obviously I just covered a tiny part of all the stuff that was talked about in the breakout sessions. It’s not clear when all the content will be released, but for now there are lots of Post Conference Blogs you can read to get the information you need.

See you next time at SharePoint Conference!