How to: Build Client Web Parts in SharePoint 2013 with Office Developer Tools RTM

Posted Tuesday, April 9, 2013 3:37 PM by CoreyRoth

This is the third time (and hopefully final) I am writing this post about building Client Web Parts (App Parts) for SharePoint 2013 with Visual Studio 2012.  This is largely due to the Office Developer Tools going through a few iterations (Preview 1 and Preview 2).  I don’t want to leave out-dated information out there, so here is the updated version.  The process remains largely the same, but a few of the screens have changed and what Visual Studio produces for us has changed significantly since Preview 1.

When you create the project, the first two steps look pretty much the same as Preview 1 and Preview 2.


The next step looks the same as well.  For our example, we’ll go with a SharePoint-hosted app again.


The good news is, in Preview 2 they’ve added a wizard that helps you get stared with client web parts.  This wizard does three things for you.  It creates an application page for the client web part, it add it to elements.xml, and it registers the CSS files from SharePoint so that the content inside the IFRAME is styled appropriately.   They have also added all of the required JavaScript files you need.  I’ll talk about those more in a second. Once you have created the project, add a new item, and choose Client Web Part (Host Web).


You’ll notice on the list that there is a new entry for Search Configuration as well.  I talked about that last week in a previous post.  When you go to the next step, you get a new dialog in the wizard that gives you the option to create a new page for the client web part.  This dialog has been updated slightly since Preview 2.


When you complete the wizard, it will generate quite a bit of HTML and JavaScript including all of the script files needed to get started referencing SharePoint.  Let me post the whole code snippet, so you can see what I mean.

<%@ Page language="C#" Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage, Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>


<WebPartPages:AllowFraming ID="AllowFraming" runat="server" />






    <script type="text/javascript" src="../Scripts/jquery-1.7.1.min.js"></script>

    <script type="text/javascript" src="/_layouts/15/MicrosoftAjax.js"></script>

    <script type="text/javascript" src="/_layouts/15/sp.runtime.js"></script>

    <script type="text/javascript" src="/_layouts/15/sp.js"></script>


    <script type="text/javascript">

        'use strict';


        // Set the style of the client web part page to be consistent with the host web.

        (function () {

            var hostUrl = '';

            if (document.URL.indexOf('?') != -1) {

                var params = document.URL.split('?')[1].split('&');

                for (var i = 0; i < params.length; i++) {

                    var p = decodeURIComponent(params[i]);

                    if (/^SPHostUrl=/i.test(p)) {

                        hostUrl = p.split('=')[1];

                        document.write('<link rel="stylesheet" href="' + hostUrl + '/_layouts/15/defaultcss.ashx" />');





            if (hostUrl == '') {

                document.write('<link rel="stylesheet" href="/_layouts/15/1033/styles/themable/corev15.css" />');








The above code differs from Preview 2 in that it also includes references to MicrosoftAjax.js, sp.runtime.js and sp.js.  Why we never bothered to include scripts this way in the past is beyond me.  In the past, we used $.getScript to dynamically load the SharePoint scripts.  That’s way over complicated when you can just get it out of the layouts directory. 

At this point, I recommend adding another script file to your project.  I tend to go with one script per client web part.  You can put all of your script code in there.  At this point, you’re also ready to deploy the client web part and try it out.  Deploy, your project, click on the Developer Site link, and then edit the page.  Click App Part and then choose your newly deployed client web part.


That should get your started.  On a related note, the JavaScript code also changed slightly in App.js (the script file for your default.aspx page).  Here’s what it looks like if you’re curious.


The new tools make it much easier to get started with Client Web Parts, so be sure and get them if you haven’t already.  Also take a look at my Preview 1 and Preview 2 posts as they can walk you through some of the other steps.


# How to: Build Client Web Parts in SharePoint 20...

Wednesday, April 10, 2013 8:25 AM by How to: Build Client Web Parts in SharePoint 20...

Pingback from  How to: Build Client Web Parts in SharePoint 20...

# How to: Build Client Web Parts in SharePoint 20...

Friday, April 19, 2013 12:29 PM by How to: Build Client Web Parts in SharePoint 20...

Pingback from  How to: Build Client Web Parts in SharePoint 20...

Leave a Comment