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:
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.
Now, let's briefly walk through the steps to combine these two nuggets of goodness:
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:
I love the new debugging stuff in Azure Websites ... so handy for those "well it works on my machine" moments. Something else i have been doing in all my Azure code is adding some tracing/debugging output using SignalR. This gives you a real time monitoring visibility in your code ... good for non-intrusively debugging your code. When you do the VS debugging for Azure it will stop other requests from executing so sometimes you need a little lighter touch if your code is in production. I wrote it up here if you are interested: