Today, I’m going to be the lazy human I’m so frequently accused of being by my somewhat faithful dog Shasta, and bring together two posts written by two other folks into one uber “ain’t it cool how this all works together post” by me. Here are the two concepts we’re combining today:
- Publishing a provider-hosted SharePoint App to a Windows Azure web site. My colleague and friend Vesa recently put together an excellent video on this process. I recommend you start by viewing it from his blog here: http://blogs.msdn.com/b/vesku/archive/2013/11/25/setting-up-provider-hosted-app-to-windows-azure-for-office365-tenant.aspx.
Now, once our SharePoint App has been published to a Windows Azure web site, the error prone and/or forward-thinking amongst you may be wondering…um, great…so what do I do to track down bugs? Well that’s where the second piece of brilliant advice that I had nothing to do with comes in.
- Learn how to remotely debug Windows Azure web sites! There is a great and really pretty simple post about this topic located here: http://blogs.msdn.com/b/webdev/archive/2013/11/05/remote-debugging-a-window-azure-web-site-with-visual-studio-2013.aspx.
Now, let’s briefly walk through the steps to combine these two nuggets of goodness:
- Create a SharePoint provider hosted app and verify that it works.
- Create an Azure web site and download publishing profile. (in Vesa’s video)
- Use appregnew.aspx to get a client ID and client secret. (in Vesa’s video)
- Publish the App to your Windows Azure site using the publishing profile, client ID and client secret retrieved in the previous steps. (in Vesa’s video)
- Create the app package, install it to your app catalog, and add it to your site. (in Vesa’s video)
- Open Server Explorer in Visual Studio 2013, right-click on the Windows Azure node and select Connect to Windows Azure…
- Expand to see all the Azure services, and then expand the collection of Web Sites.
- Right-click on the Azure web site where you published your provider-hosted app and select Attach Debugger.
- The browser opens to your Azure web site, and VS.NET starts up in debugging mode. Set your breakpoints in your code and start debugging!
See the remotely debugging Azure web sites post for the details on pre-requisites, but in short you need Visual Studio 2013 and the Azure 2.2 SDK for VS 2013; you will find a link to that in the blog post. (NOTE: that same post also describes how to do this with Visual Studio 2012 but I have not tried that) This actually works pretty great and I was able to get a first-hand experience using it when I went through the steps for this blog post. As it turns out, the SharePoint site where I installed my sample application uses the Url https://sps2. Well, the problem of course is that in my Azure Web site, my code was trying to make a CSOM call to an endpoint at “sps2”. That works great when I’m in my lab environment, but out in the interwebs that Azure lives in of course it cannot resolve to a simple NetBIOS name (remember, this code is running server side, not client side). So as a result it was blowing up. By using this cool new debugging feature I was able to find my issue, appropriately for this debugging post. Here’s a screenshot of it in action: