Understanding Paths in ASP.NET

There are more than 30 methods in ASP.NET classes that deal with paths and/or URLs. Many developers coming from traditional ASP tend to stick with the methods they know from ASP (which are still there), but there are many other useful methods that can save you a lot of time and headache. Fritz Onion covers the details of managing paths and URLs in ASP.NET, looking at everything from virtual to physical path mapping to root path reference syntax.

A quick scan of the classes in the System.Web.* hierarchy reveals more than 30 methods that deal with paths and/or URLs. In this article, I will cover the more commonly used path and URL functions in ASP.NET—presenting what they do, how they work, and when to use them.
The best way to understand what each of these functions and properties do is to try them out and review the results. I have prepared a page that makes calls to the most commonly used path functions and properties in ASP.NET, which you can download from http://staff.develop.com/onion/pathsample.zip. I recommend that you download this file, unzip it, and place the contents in a virtual directory on a machine with ASP.NET installed. Try to access the pathsample.aspx page from a browser, inspect the results, and refer to your running page as you read the rest of this article.
In case you're not near a suitably equipped computer to run the page, Table 1 shows the results of running the test page. This page was run and expressions were all evaluated in the context of a page called client.aspx, responding to a request made to the following URL http://localhost/informit/subdir/pathsample.aspx/extra. The physical directory on the Web server corresponding to this virtual directory mapping was c:\mywebdirs\informit\subdir, and the top-level virtual directory for this application was called informit and was located at c:\mywebdirs\informit.

Table 1 Path Functions in ASP.NET and Their Results

Expression	Evaluation
this.TemplateSourceDirectory	/informit/subdir
Request.MapPath("log.txt")	c:\mywebdirs\informit\subdir\log.txt
this.MapPathSecure("log.txt")	c:\mywebdirs\informit\subdir\log.txt
Request.Path	/informit/subdir/pathsample.aspx/extra
Request.FilePath	/informit/subdir/pathsample.aspx
Request.CurrentExecutionFilePath	/informit/subdir/pathsample.aspx
Request.PathInfo	/extra
Request.PhysicalPath	c:\mywebdirs\informit\subdir\pathsample.aspx
Request.PhysicalApplicationPath	c:\mywebdirs\informit\
Request.ApplicationPath	/informit
Request.Url	http://localhost/informit/subdir/client.aspx/extra
Request.RawUrl	/informit/subdir/pathsample.aspx/extra
Response.ApplyAppPathModifier("foo.aspx")	/informit/subdir/foo.aspx
this.ResolveUrl("~/client.aspx")	/informit/pathsample.aspx

Path Mapping

We start by looking at one of the most commonly used path methods in ASP.NET: MapPath. This useful function converts a virtual path into its corresponding physical path and is typically used to read or modify physical files on the server in the context of a Web request. It is available through the HttpRequest object, and for backward compatibility with classic ASP, it is also available through the HttpServerUtility object (accessed via the HttpContext or Page Server property). As an example of its use, suppose you wanted to write an entry into a log file when a page was accessed. Assuming that the log file is named log.txt and is located in the same directory as the .aspx page that is accessing it, you could write to the file with the following code:

// within a method of the Page class
string logfile = Request.MapPath("log.txt");
using (StreamWriter sw = File.AppendText(logfile))
{
 sw.WriteLine("I was here at {0}", DateTime.Now);
}

Notice in Table 1 that the call to MapPath with a string of log.txt resulted in the complete path c:\mywebdirs\informit\subdir\log.txt corresponding to the physical location of the virtual directory accessed in the request. In general, any time you call MapPath, it prefixes the string you pass in with the complete physical directory path to the current directory to which the request was dispatched. This is useful any time you need to access a physical file on disk that is placed in the same directory as your page, particularly for things such as loading XML files, writing to log files, and performing file manipulation.
Be aware that any time you access the file system from within an ASP.NET application, you are operating under the restrictive rights associated with the ASPNET account (or, in Windows Server 2003, NETWORK SERVICE). This account is specially created for ASP.NET on your machine, and by default is granted only User privileges. In a typical installation, this means that you cannot modify existing or create new files from within an ASP.NET page. If you find yourself wanting to use MapPath to modify or create files, the best solution is to grant the ASP.NET account write and modify privileges to that one subdirectory.
There is an additional function for performing virtual to physical path mapping in ASP.NET called MapPathSecure. This method, also of the HttpRequest class, differs only in the fact that it makes a File I/O security demand as you request the translation, but it is used internally in many of the ASP.NET methods. This demand is not the same as requesting whether the account has privileges to write to a file, but rather whether the code that is currently being executed has sufficient trust to perform file I/O (done through a code access security or CAS check). Most of the time, your ASP.NET code will be running with full privileges, so this function will always succeed. It is possible, however, in ASP.NET 1.1 to specify a lower trust level at which to run your application using the trust element in your configuration file (or more likely, for some third-party host environment to run your application at a lower level of trust). If this is a possibility for you, then it may make sense to call MapPathSecure instead of MapPath, as it will trigger a code access security exception sooner rather than later, giving your more flexibility in dealing with the failure.
There are two other potentially useful properties available in the Request object: PhysicalPath and PhysicalApplicationPath. The former is the complete physical path to the endpoint that was requested, and the latter is the complete physical path to the root of the application.