The customer was working on a WinXP machine joined to a domain, but had logged in using a local account (I’ve not tested if this may have contributed to the problem so this may be a useless information). Anyway to make things easy I connected to the faulting machine using EasyAssist to have a better look at the configuration: everything looked fine both in IIS and Visual Studio. Interestingly browsing the application from IE directly we found that even if he was using “http://localhost/app” the page was shown in the “Internet” zone (hence the debugger error).
This usually happens when the application is created using either the IP address or the FQDN (Fully Qualified Domain Name) of the web server; to verify, we created a new test project as “http://localhost/test” but got the same debugging problem, and again the page belongs to the Internet zone. As a test we enabled “Automatic logon with current username and password” for the Internet zone and then the debugging started working fine.
Talking about this with my team colleagues they suggested uncheck “Automatically detect intranet network” in the “Local Intranet” settings and enable the three remaining checkboxes; this because under some circumstances IE may fail to correctly detect the local network and assign it to the right zone (here is where I’m not sure if logging in with a local account may have an impact).
Then, while testing the application we noticed that Response.Redirect() calls where not redirecting the page as expected (we just got a blank page, but this may vary a bit); the customer was using SmartNavigation, and this in conjunction with the redirect problem usually means a problem with the client side .js file which may be corrupted… run aspnet_regiis -c and you should get rid of it.
Problem solved ?
Carlo
Quote of the Day:
Civilization begins with order, grows with liberty, and dies with chaos.
–Will Durant