After the setup of a new SharePoint 2013 environment, I started testing it by creating a really simple SharePoint-Hosted App, like a basic “Hello World” App. For this environment, I am using a Visual Studio 2012 development machine remotely from the SharePoint 2013 box. In order to test this very simplistic application, I just pressed F5 to launch the VS debugger and I landed on the SharePoint 2013 page, and was able to see my App in the quick launch menu. But when I clicked on the link, I got a nice “The resource cannot be found” (404), as show in the picture at the beginning of this post.
I checked several times the SharePoint 2013 App settings, such as the “App domain” URL and the “App prefix”, and they were correct. I also checked the DNS settings and the bindings to the IIS site and everything was perfect.
During my troubleshooting, I saw that deploying manually the App was working perfectly. It means that there was a difference between a deployment using VS and a manual one, or, the execution of the App.
Googling a bit, I found this post on the Microsoft forums : http://social.msdn.microsoft.com/Forums/en-US/appsforsharepoint/thread/188d78d8-8c35-46df-8770-695d1258ad18/
In this long thread, people are mentioning that they were adding a colon to the loopback IPv6 address that VS is adding in the hosts file (located in %Windir%\System32\drivers\etc ), making the address ::1 invalid. This indeed worked for me, but raised another question. VS was adding two IP addresses for the same host :
Clearly, ::1 is the IPv6 equivalent of 127.0.0.1, but my App was not running locally, but on the 10.180.128.195 server. So, why the IPv6 was wrong and not equal to my SharePoint 2013 IPv6 address ?
While in debug mode, I replaced the ::1 address by the real IPv6 address of my SharePoint 2013. And………it worked like a charm.
So far, my theories are (and be cautious, because they need to be confirmed), coming from many different tests I did :
- By adding a colon to the loopback IPv6 address, it makes it invalid (rfc5952). This causes my development machine falling back to IPv4 to connect the server.
- The reason why VS adds the loopback IPv6 instead of the correct one is likely because it cannot resolve the host name with IPv6. And rather than not adding any entry, it adds the ::1 address.
As also written in the MSDN forum, to avoid having to every time manually change the hosts entries while in a debugging session, disabling IPv6 is a good way, and most probably not an issue for most of the people.