.NET Answers

See this picture?

That’s what could happen to your application if you decide to build your ASP.NET web site using the File System location instead of the HTTP location.

To illustrate, let me relate a situation that came up when I first started using ASP.NET back with Beta 2 of 1.0.

Prior to ASP.NET 1.0, I had built an application using a combination of Java and C++ that allowed us to use Visual Source Safe over the Internet.  When .NET came out, I had some time and decided to port the application over to .NET.  The port went rather smoothly and I was able to add some features using .NET that I wasn’t able to add using Java, primarily the Visual Studio integration.

The transport mechanism for the .NET version was Web Services.  The web service would call the VSS COM object to get the directory structure, permissions, and to get and check in the file.

Everything worked fine in Beta 2, but when the release version came out, everything suddenly stopped working because the release version of ASP.NET had all the security stuff implemented that wasn’t in the Beta.

You can run into the same issue today by using the File System because when you develop using the file system, you are running the ASP.NET application as yourself rather than as the user account that would run the ASP.NET account if you were running it under IIS.

Most of the time, this would never be an issue.  But your development environment should always look as much like your production and test environments as is possible.  This includes using IIS with the same security roles, file permissions, database access, and any other environmental issues that may be unique to your application.

That way, when you finally deploy your application to production, you can be relatively sure it will work just like it did when you developed it.

Just like the driver of the car above, just because you’ve never had a problem driving 80MPH on a 55MPH road before doesn’t mean you can keep doing it and get away with it.