Unless your code explicitly checks the domain name, you should be able to deploy on II7 and test through http://localhost.
There are few caveats with this approach, though:
- if you are using third-party API that requires a key tied to the domain name of you app, you might have to request two keys - one for the domain name (for PROD purposes) and one for localhost (for DEV purposes). I do that with both Google Ajax API and Facebook Connect keys.
- http://localhost is in different security zone in IE than regular internet sites, so if your app uses any AP that requires cross-domain communication (like Facebook Connect), you might have problems testing on IE7. Works like a charm on Chrome and seems to work properly on IE8.
- if you are working on multiple apps at the same time, you can't have all of them listen on port 80 at the same time. SO, some of the apps will have to be moved to http://localhost:8080 or another port.
My approach is to run the VS Dev WebServer (Cassini) on ports 808x during developing and to deploy to the local IIS7 (using CruiseControl.Net) on ports 888x. This allows me to debug easily with VS while working on the code, yet still have the site set under medium trust on IIS7.
I also have a host name on the target domain pointing to my dev machine, so the IIS7 instances are available both as http://localhost:888x and http://dev.domain.com:888x, which allows me to also test the domain integration with Google Ajax and Facebook Connect APIs. Of course, this requires control over the domain DNS and the ability to add an A record to it.
However, note that nothing in this setup requires actual testing on the domain URL.