Problem: When you upgrade your Visual Studio solution to VS 2012, the Web Applications that run inside the Visual Studio no longer resolve the localhost to 127.0.0.1 which is the IP4 loopback address. Instead it resolves to ::1 which is IP6 loopback address.
We faced this issue when we tried to upgrade our .net 3.5 solutions for VS 2010 and earlier to VS 2012. Rest of this post is about analyzing the issue and evolving a solution to the problem.
Our application is looking for UserHostAddress property on incoming requests and expecting it to be in certain format, IP4 4 octect format, in various parts of our code. This is, of course, a design smell. While this intimate reliance on low-level detail may be avoided in distant future, we were struck with VS 2012 solution that we can't run.
I tried to change hosts file (C:\Windows\system32\etc\drivers\hosts). It did not help. When I researched this problem on the web, most solutions suggested to disable all of the IP6 components. This is certainly feasible via registry manipulation and a restart. While this may solve the problem but it is not recommended by Microsoft.
Actually there is no problem with IP6 on your machine. Neither .net nor Windows 7 are culprits here. My lucky break came when I typed 127.0.0.1:57574 instead of going to localhost:57574 as my VS 2012 does. The UserHostAddress is no longer ::1 but it is 127.0.0.1 as expected by my application. The problem was due to the way Cassini (WebServer.exe, comes with Visual Studio) handle the incoming requests. It translates the localhost as IP6 loopback ::1 instead of 127.0.0.1.
Here I suppressed the Cassini’s urge to
translate the string localhost using latest technology. This solution
does not need any mucking of the registry and hence your spanking Windows 7 (or Windows 8) works perfectly for ,those components that may rely on IP6.
True to my calling, I am too
lazy to type 127.0.0.1: 57574 , hence I mustered my energy to find an
alternative that does not require me to type 127.0.0.1: 57574 every time I
launch the application from inside Visual Studio 2012. Fortunately VS supports
my laziness, no wonder companies are paying a lot of money for this reason
(developer productivity). All you need to do is to right clicking the
Website project and selecting “Property Pages” , then “Startup Options” , and
typing “127.0.0.1: 36869” in the “Start URL” box. This works perfectly also.
The only problem is that it saves this option in binary .suo file rather than .sln which is a text file. Depending on the policies and policing of your configuration management system you may or may not be able to check-in .suo file.
