Ok, a bit sooner as I had expected; but here’s my first tech post on SharePoint 2013.
I was trying out some of the examples found on MSDN for creating SharePoint 2013 apps, such as this one: http://code.msdn.microsoft.com/SharePoint-2013-Hello-0fd15fbf. I kept on running into several problems; beginning with the infamous “object reference not set to an instance of an object” nullreference exception. After some scooping around in the matching TokenHelper.cs file, I noticed it had something to do with setting up a connection to the access control service (ACS) at Microsoft.
At my office, we’re behind a ISA firewall / proxy which handles incoming and outgoing data. I had a suspicion my problems could be caused by that. But normal internet traffic (IE, webradio, you name it) all works fine, so why wouldn’t this?
I used Fiddler to see what was going on behind the scenes. And hey! It suddenly started working without any errors. Fiddler replaces the IE proxy settings with it’s own and if you have configured a proxy; it routes all traffic there after catching it. So now my requests were routed through Fiddler and then forwarded to the proxy.
Our proxy is configured by a automatic configuration script. The “use a proxy server” textbox is empty. Fiddler uses this box though, bypassing the script. So I opened the script and found the proxy URL being used. I then insterted that into the “use a proxy server” textbox and there we go: no errors any more.
If you don’t want to use that textbox (if you don’t want to switch it off when you come home each time for instance), you need to explicitely tell the app to use a proxy. You can do this by editing the web.config file and adding:
<proxy usesystemdefault="False" proxyaddress="http://proxyaddress:8080" bypassonlocal="False" />
Conclusion: when using an automatic proxy script, asp.net doesn’t discover your proxy correctly. Set the proxy details in web.config and you’re good to go.