Why You Debuggin'?
Debugging with IIS in Visual Studio 2008
Most of the time, debugging an ASP.NET web project in Visual Studio 2008 with the built-in web server is sufficient. However, there are times when debugging with local IIS is not only preferred but necessary.
We recently worked on a project that used IIS virtual directories to store user file uploads. The application is running in an admin environment and production environment, so creating virtual directories was a convenient way for the web application in both environments to access the same files.
To test the setup, we created a folder on a local machine where the virtual directory points to and gave the folder the proper read and write IIS permissions (IUSR, IIS_IUSRS). Next we created the virtual directory in IIS.
Running the code locally using the usual "F5" method of debugging in Visual Studio 2008, we uploaded and saved a file. When we checked the physical directory where the file should have been saved, it was not there. Rather, a new folder was created in the web application root directory with the same name as the virtual directory. What gives?
We came across two issues here:
- The file was saved using the virtual directory path, but instead saved to a relative path
- The folder could be created at the application root, even though read-only permissions are specified for the IIS accounts.
We realized the virtual directory wouldn't work while debugging because it is an IIS virtual directory.
A quick google search on how to debug using IIS in Visual Studio revealed this IIS site, which includes excellent instructions on setting up your machine to debug in IIS. Note how the term "machine" is used and not simply "Visual Studio"; Windows configuration changes need to occur to enable IIS debugging.
Once we set up Visual Studio IIS debugging, the virtual directory worked as expected.
IIS Debugging Advantages
By default, Visual Studio is configured to use its built-in web server. While this is convenient, here are a few advantages for using IIS to debug:
- Closely mirrors the production environment. More than likely, your production code will be running on Windows Server using IIS. In principle, it is always best to test in an environment as close as you can get to the environment that the code will run on.
- Permissions. The built-in VS web server seems to run with full read/write permissions. If you're doing anything with files, you may forget to configure folder permissions on the production environment because all of your file operations just "worked". Using IIS to debug will force you to think about folder permissions. Unless you gave full read/write access to your whole web directory, which is definitely not advised, you will get an IO error when trying to write to a folder you didn't explicitly give write access to.
Afterthoughts
These days, hardly any developer works solo. We all work in teams and other developers on the team may use the built-in VS debugger. Would everyone be required to make the changes too?
Fortunately, no. As mentioned earlier, the credentials that the built-in VS web server uses seem to have full read/write access to the web project folder. So if another developer on the team needs to test the upload functionality locally, they will have no problems. The file upload folder will just be created at the root of the web project.
Conclusion
Even if you don't debug using IIS, we strongly recommend to at least test your web app locally using IIS. Especially if you're doing file operations, you may be glad you did.
Comments? info@upperstrata.com