UPDATE – 4/8/2008
I've collected the various how-tos and gotchas about using Visual Studio 2005 and Visual Studio 2008 with IIS 7.0 applications into two detailed articles:
Using Visual Studio 2005 with IIS 7.0
Using Visual Studio 2008 with IIS 7.0
Be sure to check them out for detailed info on working with both local and remote IIS 7.0 applications on Windows Vista SP1 and Windows Server 2008 RTM, doing local and remote debugging, and other stuff.
Last time I wrote about debugging on IIS 7.0 was Fix problems with Visual Studio F5 debugging of ASP.NET applications on IIS7 Vista. Since then, a hotfix was released for Visual Studio 2005 that makes debugging IIS 7.0 applications easier, and solves the problem of debugging on Vista Home Premium which does not have the Windows Authentication component of IIS 7.0.
Now, with Visual Studio 2008, debugging IIS 7.0 has gotten easier. In fact, debugging local apps is a breeze, but there are still some gotchas you may experience when trying to debug remote IIS 7.0 applications. This is especially the case if you are debugging an application in a workgroup environment (your Visual Studio 2008 client and the remote server are not members of the same domain).
NOTE: This post is about debugging web applications on a remote IIS 7.0 server using Visual Studio 2008, in a workgroup environment (not domain).
If you need to do this, here is what you need to know:
1) You need to use a synchronized Windows account (an account with the same username / same password) on both machines. This account must have administrative rights on the remote server.
If you are using Windows authentication in your application, this MUST be the built-in Administrator account. If you are using Anonymous authentication, or Basic authentication, or some other authentication mechanism, it can be another account but still must be a member of the Administrators group on the remote server).
2) Install the Remote Debugging components on the remote server machine. These typically are on your VS 2008 CD#4 or on the DVD.
You can run the Remote Debugging monitor (msvsmon.exe) from a share, but then, you won’t be able to use F5 Debugging – only the Attach to Process debugging.
3) Log on to the remote server as the account your created in step#1, and run the Remote Debugger from the Start menu using “Run As Administrator”.
Important: you must log on as the synchronized account, it must be an administrative user on the server, AND no you cannot use RunAs.exe to start it because UAC will prevent it from running as Administrator.
You can also set up msvsmon.exe to run as a service, by running the Remote Debugger Configuration Wizard. Then, you need to make it log on as the synchronized account, AND, must grant this account the right to “Log On As a Service” through the Local Security Policy console. It won’t work if you let it run as LocalSystem.
4) Log on to your Visual Studio computer using the synchronized account. Start Visual Studio 2008 with “Run As Administrator”.
5) Open the IIS 7.0 Web site remotely using Visual Studio via “File – Open – Existing Web site …”. Now, here you have a few different options:
· “Remote Site” – this requires Front Page Server Extensions to be installed on the remote server, and the web site in question must be enabled for FPSE. FPSE RC1 release is available as a free download for IIS 7.0. Get it and read more about it here. This also requires Windows, Basic, or Digest authentication to be enabled on your web site.
· “FTP Site” – this requires you to share the Web site or virtual directory using FTP. You can use the built-in FTP server in Windows Server 2008 or download the FTP 7 RC0 release on the web, and then configure the URL of the site in custom web server settings in project debug tab.
· “File System” – this requires you to share the Web site root or virtual directory using Windows sharing, and then configure the URL of the site in custom web server settings in project debug tab. This may be the simplest way to get started because it doesn’t require installing any publis
Now, final note about authentication:
If you are using Windows authentication, you MUST be using the built-in Administrator account (with synchronized passwords) to run Visual Studio 2008. This is due to UAC preventing VS from authenticating as an administrative user when using F5 attach.
If you are using Basic authentication, or Digest authentication, you can use any synchronized account as long as it’s got administrative rights on the remote server. This makes Basic authentication the ideal choice for setting up remote debugging using the “Remote Site” option (normal Basic authentication security concerns apply – don’t use on the Internet without SSL).
If you are using the “File System” option with the file share, then you don’t need any authentication (meaning you can use Anonymous authentication) on your site, and can use any synchronized account again as long as it’s got administrative rights on the remote server.
Damn it, it’s not working.
Check the following:
1) Did you do everything I said above? Re-read it and make sure you did.
2) You must use the synchronized account that has administrative privileges on the remote server.
3) You must run msvsmon.exe using the synchronized account, AND, “Run As Administrator”. Don’t use RunAs.exe.
4) You must run Visual Studio as the synchronized account and “Run As Administrator”. Don’t use RunAs.exe.
5) If using Windows authentication on your site, you must use the built-in Administrator account (with synchronized passwords).
6) While this is the default, make sure that the “Network Access: Sharing and security model for local accounts” option is set to “Classic” in the Local Security Policy console. For more info, see Gregg’s post.
6) You must install FPSE and FPSE–enable your site to use the “Remote Site” option.
7) You must use Windows, Basic, or Digest auth in your site to use the “Remote Site” option.
I am putting together a more detailed articles about using Visual Studio 2008 with IIS 7.0, the publishing options, and debugging, that will be published on iis.net soon. But this should help people get started.