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.