Category Archives: Development

SharePoint Intersections conference, MGM, Las Vegas, Oct 2013

Missing your yearly SharePoint fix in Vegas?  Look no further!

SharePoint Intersections is a new conference happening at the MGM Grand in Las Vegas, October 27 – 30.  They have a great set of sessions planned and its definitely worth taking a look at it.  ASP.Net, Visual Studio, Azure and SQL Intersections all happen at the same time in the same place … so its not just a bunch of SharePoint people to hang out with too 🙂

REGISTRATION DISCOUNT: Get a $50 discount!  Use the discount code “JOHNSON” during registration!

Bonus:  If you Register for the SHOW or COMPLETE package you get a Surface RT or XBOX or gift card!

I have the great privilege of running a one day pre-con workshop on SharePoint App development alongside Andrew Connell:

PRECON08: Getting Your Arms Around the SharePoint 2013 App Model (10/27 8:30am-4pm)

As well as the following sessions:

  • SP05: Working with SharePoint APIs Remotely

  • SP06: Apps for SharePoint Primer

  • SP04: Soup to Nuts how to Build a Metadata and Search Driven Intranet

For more information see:

I hope to see you there!


Integrating SharePoint Online and Yammer – An app for that!

Way back at SPC12 (Nov 2012) the keynote included a demo that showed an example of the integration possible between SharePoint Online and Yammer that could be done with a little bit of development effort. I built that demo and decided to turn it into a real app anyone could use.

Some Background first: This surfaced in SharePoint Online by way of a new ribbon button that when pressed posted the selected document to Yammer via the Yammer Open Graph API.  It was shown pretty quickly and it was pretty easy to miss.  However, it demonstrated a few interesting methods of integration that are possible today using the new SharePoint App plumbing and Yammers pretty decent set of APIs.

The basic flow

1. In a document library a document was selected like this


2. Then in the ribbon a new “Post to Yammer” button showed up


3. When it was clicked it posted to the Yammer activity feed. 


The image above shows the hover over the activity. 

The activity feed shows a scrolling history of activity in the the Yammer network.  e.g. “Chris Johnson updated Product Catalog.docx”.  Its like that thing in Facebook that shows you all the music that your mates are listening to that they probably don’t know they are publishing to all their friends via spotify.  More on the Activity feed a little later on.

4. Clicking on the activity will take you a page in Yammer for that activity where you can Be Social™ and discuss the document, like it etc…


How it’s made

This app is pretty simple.  It’s a SharePoint Provider hosted application running in Azure Websites.  The SharePoint part of the app includes some xml to add the ribbon button to all document libraries.  When the user clicks the “Post to Yammer” button it sends some details about the document(s) to the backend of the app running in Azure. The backend code then uses the CSOM to call back into SharePoint to retrieve the name of the document and some other properties. Then the app directs the user through the Yammer OAuth authentication flow.  Once this is complete the app then is able to access Yammer on behalf of the user that signed in.

Finally the posting of the information includes posting to the Yammer activity stream using the OpenGraph APIs (JSON/REST based). It will also post to the main feed in Yammer too via the Messages REST API in Yammer. Both of these are easy to use and are fairly standard XML/JSON/REST based services.


Why is this interesting?

Recently there has been a bunch of noise about SharePoint’s current dual headed social story. 

  • In the red corner you have the social features in SharePoint (both on-prem and SharePoint Online)
  • In the blue corner you have Yammer.

The problem is that right now there is much consternation about how they don’t work nicely together. Things seem to be happening too slowly for some people.  The products are currently not integrated all that well. That is slowly changing, like the ability to switch from the NewsFeed to Yammer in Office 365 that rolled out the day of writing this post.  Those improvements will continue over time and eventually I think we will see the ability to totally replace the current out of the box social features with Yammer.

How on earth people think Microsoft can magically mash together one product with another overnight and make it all work perfectly is beyond me. It will take time people! Just because you think you could have done in overnight doesn’t mean it works that way in huge software projects … better stop this rant now before i get carried away.

The short story is that right now you have to pick one or the other.  My vote is firmly in the Yammer category. But at the end of the day there are many factors that will go into your decision either way and there isn’t a perfect answer.

There is no doubt that Microsoft will integrate the two products more deeply.  This could come in a variety of flavors including:

  • surfacing stuff that happens in Yammer in SharePoint more seamlessly (short term strategy),
  • totally replacing the existing SharePoint social features with ones backed by the Yammer in the cloud (more likely and what I would put money on, maybe with the ability to use the old stuff if you can’t use a cloud service)

Back to why this integration is interesting…

You can do things today to help with this situation.  The demo showed a very basic example of some custom integration using things we know exist today.

I smell a set up!

… and you would be right.  We are going to release this app to the store so that anyone with Office 365 can use it.  It needed some tweaks to make it work well in production & some branding changes. However in the coming days/weeks we will release it under the name “ShareIt”.


I am going to write a future post on how this app was created and it will include code to illustrate how to call the Yammer APIs.

Ultimately you should be able to follow along and learn about how you can leverage the SharePoint App model + Yammer APIs to help integrate the two products while we wait for MS to offer a nice compelling seamless integration at a yet to be determined point in time 🙂

Note: It is very likely that this app will no longer be needed once MS do their thing and integrate the products further.  I hope so to!


TechEd North America session wrap up


This morning at TechEd North America i did a session on Office and SharePoint 2013 App development.  In a nut shell it was 75mins of demos (8 or so).  It was a mix of things I have found handy developing Apps, things I think are going to play an important role in App development (SPA apps) and other things that I think are handy for those getting started with App development.

Here is a summary of the demos:

#1 SignalR:  Using SignalR in your apps backends for watching trace and debug information from your application. Great for when your code is running in Azure and you want visibility into what is going on.

#2 Token Caching: When you first are starting out with app development its not entirely obvious what all the tokens and parameters are that are passed to your app code. OR how to work with them.  This demo was all about showing a lightweight way to cache and store the tokens for use in subsequent pages.

#3 Use OAuth to access SharePoint from apps for Office:  This showed how to do “on the fly” OAuth from a task pane App in Excel.  This lets an application ask the user for permissions to SharePoint resources when needed. In the example i showed Excel, but you can do the same from a SharePoint app.

#4 / #5 The SharePoint cross-domain library: Two demos showing techniques for calling out to external services (in this case my blog) from JavaScript running in a SharePoint hosted app.  Also how to set up the CSOM for calling into the Host Web SharePoint site where you app is installed.  Both scenarios show cross domain techniques available.

#6 Bring Office documents into your SharePoint apps with the Office Web Applications:  Most people have seen the document preview windows you get in SharePoint search and document libraries that use the Office Web Applications. But you can also use these in your own Apps too.  Great way to show documents alongside your App content.

#7 SPA Apps:  Single Page Applications.  Very kindly Andrew Connell allowed me to show his recently built Learning Path Manager demo which showcases an App built using Durandal, Knockout, Bootstrap, FontAwesome, LinqJS and Toastr.  Finally SharePoint development has been possible using frameworks, tools and techniques that are moderns and current.  All the cool kids are doing this stuff and I think its going to be a very interesting option for SharePoint app development going forward. For source and more information please refer to AC’s blog post. 

#8 App CSS makes your app look like part of the experience: A simple demo showing how to use the Chrome Control and SP CSS in your provider hosted apps.  I skipped this in the session due to time.

#9 Elevate your SharePoint app’s permissions with app-only calls: No more running code in process as system!  The App model provides a fairly elegant way to elevate permissions without losing control of an apps privileges! Apps can make “app only” calls to SharePoint to do things that the App has rights to do, but not necessarily the user using the App.

#10 Yammer Integration – Bring your app to where users are by posting to the feed:  Yammer provides some nice APIs to work with.  For example REST APIs for posting the feed & OpenGraph APIs for posting activities.  I demoed an App called “ShareIt” that takes a document and posts it to Yammer. The app will hopefully be in the 365 marketplace shortly (free) and I hope to do a follow up “how it works” blog post on it + full source for the app.

Slides: (they are boring … just intros to the demos)

Demo files: The zip below contains the demo files for demos #1 – #6 and  #8 and #9.  SPA code comes from AC here and the ShareIt code (Yammer) will come out as part of my new blog on that App shortly.

The recording of the session will be up on Channel 9 in the next 24-48 hours i am told:

Happy App’ing!


Revisiting SharePoint development 6.5 years later…

Way back in 2006 I wrote a blog post entitled “Application Development on MOSS 2007 & WSS V3” that discussed the various options for building apps on SharePoint. It’s been by far and away the most viewed blog post I have written. As of writing its sitting at 140,000 views.  

The main point on writing that post 6.5 years ago was to provide a simple summary of the options available for development in SharePoint 2007. At the time those were:

  • Web Parts
  • _Layouts application
  • User Controls
  • ASPX pages added to a site with code behind

Towards the end of the post I summarized the choices in a simple decision matrix (below):


Now fast forward to 2013 and the new release of SharePoint 2013 … Most of that matrix still holds true albeit with a couple of minor tweaks. Back when I wrote the original post there was no support for SharePoint built into Visual Studio for example.  Today instead of the Smart Part (thx again Jan Tielens) you can use a Visual WebPart (which is a user control that is compiled down to a server control by Visual Studio, but which gives you the benefits of the visual design surface at design time, unlike a standard WebPart).

Given so long has passed I thought it was about time that I revisited the choices and took a look at what has changed in the last 6.5 years!

Before I go on, I want to reiterate that this is my personal opinion. Many of you won’t agree.  So this is really just a summary of the decision matrix I use in my head when evaluating the options and deciding on the best choice for the situation.

Evolution of the matrix…

Updating this matrix is a lot trickier now we have SharePoint Online where many of the pervious on-prem options don’t exist. e.g. no full trust code.

I went back and forth on deciding what my updated matrix would include. This took a while and, given I am a big proponent of SharePoint Online, I would prefer everyone think about designing their solutions with the possibility of moving to SharePoint Online in future.

Why?  Well in a recent internal email amongst developers here is what I said (some bit snipped):

Apps should be our first choice moving forward.

The reason is simple.  There is no future in Sandbox Solutions or Full trust solutions.

Notice i said “first” .. not only 🙂 When will Sandbox Solutions go away? Shortly after the new app model supports everything you can do in a sandbox solution. MS will deprecate it as fast as they can and then turn it off after giving  everyone a year to re-write their code.

Trust me, MS wants to kill sandbox solutions as fast as they can.  Same with full trust code. It gives SharePoint a bad name when SharePoint fails … even because of code someone else wrote and deployed to it.  The sandbox is too expensive to run in Office 365 and therefore will be shot. To be clear, the goal is to remove any 3rd party code running within a SharePoint process. Doing so will improve the security, scalability and reliability of SharePoint.

Now that might sound a bit harsh … and to be fair I was trying to be … but my point is the long term vision for SharePoint is to not host other peoples code.  The new app model might not be a perfect replacement today … but given time I’m willing to bet it will get better and support more of the things you can’t do today.

Then I went on…

For now we should be thinking Apps first … and augmenting it with sandbox and full trust only when needed.  Otherwise we are painting ourselves in a corner. This is most important for 365 solutions.  Still, 2 years from now we shouldn’t be having to explain ourselves to our customers for painting them into a corner where they can’t migrate to 365 or upgrade to the latest version of SharePoint because of our recommendations. Not good.

Don’t get me wrong.  I’m not saying “no sandbox” and “no full trust” … i’m just saying we should be leading with apps first and then backing in sandbox and full trust only when needed.

I like apps because they also mean we are not constrained to what development options SharePoint imposes like MVC or the latest improvements in the .Net framework.  Because your code runs remotely you can run it on anything you like. It could be PHP for example.

<mega tangent> PS: can we start a petition to stop calling the new model the “app  model” and call it something like the “remote code model” that “apps” happen to use. Then we can reserve “apps” for stuff that gets put in the Marketplace. I know this won’t happen but it would be nice 🙂 “Apps” was a bad idea IMHO.</mega tangent>

Back to the matrix…

After going back and forth on it for a while I came to the stark realization that a matrix was no longer required.  Dev has got simpler for a change!

So here is my new “matrix” … or the “Decision List 2013 edition” as I am now calling it:

  1. Design Manager package (on-prem or online)
  2. App for SharePoint (on-prem or online)
  3. Sandbox Web Part (on-prem or online)
  4. Full Trust Web Part (on-prem only)
  5. Full Trust everything else (on-prem only) (_layouts pages etc…)

It’s pretty straightforward when you think about it.  Start with the lightest touch possible and only step down to the next heaviest when you have to.  This might seem screamingly obvious, but it would surprise you (or not) how many developers jump for the most heavy weight option first because it’s the most powerful and they don’t have to think.

Further more option #2  above can be further expanded to:

  1. SharePoint Hosted App
  2. Provider Hosted App

You may notice the absence of the Auto Hosted app type above. This is the option where you package your application and SharePoint will automatically host the application code for you in Azure. Reasons for this are simple A) its not available (yet)  B) it’s horrid (my opinion).  Auto Hosted apps code runs in Azure space managed and controlled by SharePoint Online … not you.  I hate the thought of having to support code running in a location I have no control over and no visibility.  For example, unable to see what is going wrong when a customer calls asking for support.  For the small price you pay hosting in Azure directly via the Provider Hosted model you will reap payback many times over when you need to upgrade your app and or diagnose a support issue and can’t tell what is going on.


Regardless of your like or dislike of the new app model there is one thing that is clear … at least to me anyway. That your code will not live inside the SharePoint process in the future. For me, that means thinking about how to start designing solutions with this in mind as to not inadvertently painting yourself into a corner that is costly and painful to get out of.  Sure, there will be situations today that mean you have no other choice to use some sandbox and full trust code.  But …

My words of advice are simple.  Think apps first and fall back to heavier options if needed.

This way over time as the new app model gets better and becomes the starting point for all SharePoint development you will already be ahead of the curve and will have an easier path to the cloud when your customers are ready.

+ ask any developer if they would rather be using MVC, Razor, SignalR etc… my bet is they say “yes”.


New Release: Office Developer Tools for Visual Studio 2012

I vividly remember penning the blog post announcing the Visual Studio Extensions for WSS (VSeWSS 1.2) .  Love them or hate them VSeWSS was the first MS foray into integrated developer tooling for SharePoint developers.  In all honesty VSeWSS was a skunk works project started by some folks in the SharePoint and SPD engineering team.  I inherited them when Alex Malek moved to the IE team.  For the 2010 release I worked pretty closely with Mike Morton from the VS team on what became the SharePoint tooling that you see today.  I am sure Mike and team hit their heads on a wall with the number of times I said we needed features like a content type and list visual designer vs. just XML.  We literally had a feature list 100s of items long and only resources to do ~30 in the first version. We eventually got the list designer a release or so later 🙂

Now we have the next major iteration of those tools that have just released for SharePoint and Office 2013!

Read the announcement here:

Randall also has a write up on them here:

They come complete with fancy colored icons in the new project picker!  (the preview was grey scale). I laugh … but the grey pissed me off for some reason.

Personally I love the mention about Continuous Integration workflows and new debugging features with service bus … and looking forward to getting my sticky hands and playing around some more.

Get them here:

Great work @chakkaradeep!!


My first book: Beginning SharePoint 2013 Development

It was a long time coming and I have wanted to do this for quite some time … but I have just heard that the book I co-wrote with Steve Fox, Donovan Follette and tech edited by Andrew Connell has just been sent to the printers!

As the name suggests … It’s all about starting development on SharePoint 2013.  As you may have read or heard there is quite a bit of new stuff for developers in 2013 and this book aims to serve as a guide for those looking to grapple with those changes.

Topics include …  the new app model, developer tools, Azure, building and packaging apps, publishing in the SharePoint Store, distributing them internal to an organization, OAuth, Client Side OM, REST APIs, integrated SP + Office apps, Remote Event Receivers, Business Connectivity Services, Office Services & Workflow.

A core theme throughout the book is learning about the new development options available in 2013 and how and when to take advantage of them.

I wrote five of the fifteen chapters …

  • Developing, Integrating, and Building Applications
    in SharePoint 2013
  • Packaging, and Deploying SharePoint 2013 Apps
  • Distributing SharePoint 2013 Apps
  • Overview of the Client-Side Object Model and REST APIs
  • Overview of OAuth in SharePoint 2013

Like I mentioned above, writing a book was something I have wanted to do for a while now but never got around to it.  I really have to thank Steve Fox for giving me the opportunity to collaborate on this.

It should be available soon and is already available for pre-order on Amazon:

Get it while its HOT!


My first Windows 8 app

Logo.scale-80Some of you may know that I make a Windows Phone app called My Trips. It’s a popular companion application for the awesome service.  If you don’t use TripIt to manage your travel plans you are missing out!  You just forward your booking tripit_proPDF or document from your travel agent, hotel, airline or whatever to [email protected] and they magically (nerd alert: read awesome search based entity extraction) parse out all the data and put it into a far for useful format that is accessible on the internet for you.

My Trips lets you sync those plans down to your phone or PC and take them with you when you travel.  As awesome as the world is these days its highly likely you will be stuck without an internet connection at the most inopportune time 🙂

I wrote the first version of My Trips as an experiment when I wanted to take a look at building a phone app for Windows Phone… one thing led to another and nek minnit everyone wants it and I had to make it into a real app and publish it. 

Long story short … it’s used by more people than I had ever hoped 🙂

So when Windows 8 came around people started asking when I would release My Trips for it.  Of course it didn’t take much convincing and I really wanted to try my hand at Win8 development.

So it was a sweet moment last night when I finally finished version 1 of My Trips for Windows and submitted it for certification.  Hopefully nothing major will come up in certification and it will be in the Windows Store soon!

Did you just port the phone version?

To answer the question, no it wasn’t a smooth port at all. In fact I would say 85% of the code is new.  I want to write a few posts about the experience of the move to Windows 8, but for now it is fair to say that the way I built the phone application didn’t exactly lend itself to code sharing.  The phone app wasn’t built with a  nice separation of concerns using something like a pattern like MVVM.  I decided that rather than continue building on the mess I would start almost from scratch and build up with Win8 version using the (excellent) Caliburn Micro framework to facilitate a clean MVVM pattern.

The resultant code is a wonder of cleanliness, maintainability and extensibility that should make it a lot easier to port to other places if needed and maintain more simply.  If you are into clean code I highly recommend taking a look at Caliburn.

So given all I really managed to reuse code wise were a few TripIt API classes and some data model classes it really was quite a bit of work to get the rest written up.  All new Views, View Models, some Models and lots of ancillary code for caching, settings etc…Hence why it took a while longer than I had hoped.

I didn’t end up getting 100% feature parity with the phone application just yet.  That will take a bit more time.  The basics are there however, syncing your trips to your device and viewing them. Additionally things like support for Snapped view in Win8 and “Fill” view (that is the opposite side of the screen to snap view).

Here are a few screenshots of v1:

Splash screen…
Trip list…
A flight…
A hotel…
Snapped view with another app on the right…

For the devs reading I chose to write the app in C# and XAML over JS/HTML.  I personally find the C# XAML experience a LOT more productive … especially when you add in tools and frameworks like Caliburn Micro.

Like I said above, I hope to follow up with a few posts about the experience in more detail and about Win 8 development in general. 

Also … drop me a note in the comments or the contact section of the blog if you need any Windows 8 development done.  I know some people 🙂


-Chris Johnson.

WordPress and SharePoint architecture similarities and … who moved my blog?

Other than WordPress and SharePoint sharing similar a capitalization strategy I noticed some other similarities…

When I left MS just over a year ago I decided that I would move from my older (and far more popular) MSDN blog. It was on an old blog engine that wasn’t great and didn’t offer the stuff the new cool kids were doing.  So I started and hosted it on  It was super simple to set up and did a lot of it for me. is like SharePoint Online in many respects. It’s a hosted version of WordPress and because it is hosted there are things that the hoster lets you fiddle with and things they don’t let you fiddle with. Much like in SharePoint Online you don’t get to poke around under the covers of SharePoint like you can with SharePoint on-prem.

WordPress Plugins … aka full trust solutions

WordPress has a concept of plugins.  In SharePoint land this is the equivalent of full trust solutions being installed on your farm.  Obviously (like SharePoint Online) doesn’t let you add these since they could do anything to the server they like and effect other customers. SharePoint Online is the same, Microsoft want to preserve the stability and security of the system for everyone hosted there.


See the similarities between WordPress and SharePoint now? 🙂

Where SharePoint is evolving is in how we get around this limitation of not being able to add functionality in a pluggable but secure and manageable manner.

Step 1: A more secure plugin model … aka Sandboxed Solutions

In SharePoint 2010 Sandboxed Solutions were introduced to offer a sandboxed execution environment for your code. This was far more limited in what you could do in there, but at least it offered some form of online friendly pluggable system.  I was working on the team that owned Sandboxed Solutions in the SharePoint 2010 release & at the time it seemed like a great solution. Remember this was before Azure existed. This was 2.5 years prior to 2010 releasing and “the cloud” was still being called “servers in a datacenter” by most people.

Step 2: An even more secure and flexible plugin model … aka SharePoint Apps

Hindsight is a wonderful thing and looking back Sandboxed Solutions is the wrong model long term. Hosting other peoples code is hard and there are better places to do that than in SharePoint i.e. Azure.

The new SharePoint App model offering remotely hosted code is a far better model going forward in my opinion.  It’s not that I am deeply into “apps” as such … it’s more that this new model offers interesting new plumbing and APIs that developers can use (see SharePoint’s new Plumbing, great for developer).

Where to from here?

Back to WordPress … it doesn’t yet offer a solutions like this (AFAIK). Plugins are full trust solutions that are installed.  In a similar vein Microsoft CRM offers a sandbox where code can run etc…

I wonder when we will see more products like WordPress and MS CRM move to the same architectural model as SharePoint 2013 for custom code and plugins?

I expect to see the new SharePoint App model, or more correctly, the plumbing and APIs that support the app model to evolve in the coming releases fairly rapidly. Allowing us to do more than is possible today and build solutions that integrate with SharePoint in new and interesting ways. The Sandbox has turned out to be a dead end and the new way forward is getting code out of the host process and into better suited places like Azure.

So what is your point Chris?

Oh … well I started writing this post to fill you in on my blog moving. Its still WordPress … but I decided I wanted plugins and all the stuff doesn’t offer.

So I moved my blog to run on WordPress on Azure Web Sites.

Yes I know this sounds like I am advocating for full trust solutions in SharePoint … really I’m not 🙂 SharePoint has a better long term solution for those now 🙂

I wanted the ability to add plugins and get at features in WordPress not offered in the hosted option.

+ I am a big Azure fan … keep up the great work @ScottGu

I won’t regurgitate all the steps to get WP running in Azure … but will point to a couple of helpful posts from John Papa who recently did a similar move.

One thing I will mention is that I had a hard time getting Azure configured to serve my site on both and  Azure Web Sites recently added support for “naked domains” aka… domains without the “www” on the front.  I found it a wee bit tricky to set up due to the requirement to set up a dummy CNAME DNS record so that Azure can check the DNS settings … so in case you are wondering how to do this I have a few screen shots below.

My DNS is hosted with GoDaddy … and the first thing you need to do is add a special CNAME DNS record that Azure checks for.

You need to create an alias for “awverify” and point it at “awverify.<your azure name> … see below…


Then in the Azure management portal click the manage domains button to map domain names to your web site


Here is my setup…


In order for Azure to allow me to add I needed to set up a CNAME record that pointed at

In the same vein … Azure would only allow me to add the “naked domain” ( once I had added the CNAME for “awverify” and point it at “awverify.<your azure name>

Anyway … I hope this helps the next person who gets stuck trying to get their Azure web site running on a root “naked” domain.  It stumped me for a while and the documentation wasn’t 100% clear.



Build a SharePoint Provider Hosted App in 5 mins

The Goal:  Build and deploy a really simple SharePoint App to SharePoint Online with the code running in an Azure Web Sites website.

Provider Hosted Apps are simply a SharePoint app where the code in your app runs in a space you provide.  That could be Azure, AWS or wherever you like. I’m picking Azure Web Sites because its free and awesome.

Before you begin:

  • Office 365 preview account (get one here for free)
  • Azure Web Sites account (get one here for free)
  • Visual Studio 2012 with the “Microsoft Office Developer Tools for Visual Studio 2012” add on installed (get it here for free)

Now on to the fun stuff….

Setting up an Azure Web Site:

1. Create a new Azure Web Sites site


2. When its created go into the dashboard for it and get the publishing profile for Visual Studio. Save it to your computer for later.


Setting up SharePoint Online:

1. Create a new Developer Site Collection in the SharePoint admin center.


2. Pick the Developer Site template when creating it


3. When your site has been created navigate to it.  Then hit the following URL to register a new App Id and Secret.  These are used for the OAuth between your App and SharePoint Online.

https://<my SPO site url><your site collection>/_layouts/15/appregnew.aspx

4. Complete the form.


  • Use the Generate button to create the App Id and Secret.
  • Put your exact Azure Web Sites domain name in the App Domain box
  • Put the HTTPS address to your site + /Pages/Default.aspx in the Redirect URI


5. Click ok and you will get confirmation the App config has been created. Make a note of all these settings someplace safe.


Creating your SharePoint App

1. Create a new SharePoint App project in Visual Studio 2012.  If you don’t see this template then you don’t have the pre-reqs installed at the start of this post. Go and install the “Microsoft Office Developer Tools for Visual Studio 2012”


2. Enter the URL to your SharePoint Online development site collection and pick “Provider Hosted” from the dropdown.  Click validate beside the URL to ensure you have got it right.  It may prompt you to log into SharePoint online to do this.


Visual Studio will create two projects in your solution:

  • SharePoint project <= this is where your app config goes
  • Web Site Project <= this is where your apps code and pages go

3. Right click the AppManifest.xml file and pick View Code to see the XML

4. Replace the “*” in the following line with your App Id you generated earlier

<RemoteWebApplication ClientId=”*” />

Should look something like this:

<RemoteWebApplication ClientId=”1B6B757E-1D3B-4375-8494-D885035A769B” />

5. Change the URL in the StartPage to the Fully Qualified Domain Name of your Azure site + the path to /pages/default.aspx?{StandardTokens} like this:


6. Open the Web.config file in your web project and set the ClientId and ClientSecret setting to the ones you generated previously.


7. Hit F6 to build the solution and make sure it compiles.

Deploying your App

1. Right click on the web project in the solution and Pick “Publish”


2. Click the Import button and pick the Profile file you downloaded from Azure previously. Go and download it from Azure if you were lazy and skipped this step earlier you naughty person.  Validate the connection to make sure its working by clicking the Validate button.


3. Click Publish and let your site deploy.  When done a browser should pop up like this:


4. Go back into the Azure management dashboard and for you site click into the Configure tab. Create the ClientId and ClientSecret app settings.  Azure websites reads them from here … even if you have them in your web.config.  So not doing this will mean your app crashes.


Oh and remember to click the Save button at the bottom of the page when you are done (yes I failed at this a number of times)


5. In Visual Studio hit F5 to deploy your app to SharePoint Online. It will package and deploy your application.

6. You will see a browser pop open asking you if you Trust your app.  OF COURSE YOU DO! 🙂 Click Trust It.


7. You will see your new app listed in the site contents.  Click It!


8. Enjoy the obligatory “Working on It” screen


9. You will be redirected to your App and should see the Title of your site written to the page like this (or whatever you called your site when you created it):


10.  BOOM! Congrats you created your first provider hosted app!

In the out of the box project templates in Visual Studio it creates a default page that uses the Client Side Object Model (CSOM) to call SharePoint Online and get the Title of your web site.  All the goo you set up with Ids and Secrets above is what is used by the CSOM to authenticate using OAuth with SharePoint online to ensure your code is allowed. The CSOM takes care of a lot of the heavy lifting for you so its all hidden away. 

When you click your app tile in SharePoint you might have seen it redirect you via the /_layouts/15/appredirect.aspx page.  This redirects you to your application via a POST along with some context about who the caller is, so that your code in Azure knows who you are & has the right tokens to call back into SharePoint as that person.

All the plumbing that makes this work is pretty detailed and way too much to cover in this post … but I suggest anyone interested read about App and OAuth in MSDN here:

Drop a comment if you have any questions or issues!



I’m looking for more peeps…

I’m on the hunt for an awesome person who also happens to code on the Microsoft Stack really well.

I know I’m a SharePoint guy … but this person doesn’t need to be!

First up here is the place to apply: LinkedIn

In a nutshell we are looking for fun people who enjoy building stuff on the Microsoft Stack.  ASP.Net, Azure, SharePoint, Windows Phone, MVC3 or 4, Web API … you name it. 

You need to be good at working stuff out, enjoy a challenging projects, clients & timelines (from time to time) … and have a pet project you work on at home in your spare time that you can show us.

This will be your view of Bellevue when you choose to come into the office:

Come and work for us!