Determine physical paths on your server in ASP.NET. You have found different ways of resolving paths, but want to know the best one. Review physical paths and virtual paths, and how to convert and combine them, while measuring performance.
I have written about MapPath before and found it to have problems. The solution to the problem here is to use Request.PhysicalApplicationPath and then append physical paths to it.
From MSDN: It gets the physical file system path of the currently executing server application's root directory.
In other words. PhysicalApplicationPath will return the location on the server that your web site is stored. It won't return any URLs for the browser.
| Property | Example value |
| Request.PhysicalApplicationPath | C:\Users\Sam\Documents\Visual Studio 2008\WebSites\PerlsCom1\ |
You must have an HttpRequest handy. HttpRequest is part of the System.Web namespace and can be accessed in a few different ways. On your aspx page, you can access the PhysicalApplicationPath like this:
public partial class Default2 : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
// Example usage of PhysicalApplicationPath in Page.
int path = Request.PhysicalApplicationPath;
Response.Write(path);
// Will write a result similar to the above table's example.
}
}Another way. The Request object can also be accessed with "HttpContext.Current.Request.MapPath." (It is best to store the Request in a variable instead of repeatedly accessing the property.)
It is faster and serves a more precise purpose. MapPath can be used to resolve the root path, with MapPath("~/"). However, that is much slower. My testing indicated that there are big performance differences between the ways of finding the application path.
//
// A.
// Find physical path with PhysicalApplicationPath and concat.
//
for (int i = 0; i < 1000000; i++)
{
string path = Request.PhysicalApplicationPath + "Dir\\File.gz";
}
//
// B.
// Find physical path with MapPath.
//
for (int i = 0; i < 1000000; i++)
{
string path = Server.MapPath("~/") + "Dir\\File.gz";
}Because it does less. I looked into the IL code here and MapPath calls result in a long chain of method calls. At some point, the "this._appPhysicalPath" field is used, which is probably what PhysicalApplicationPath uses too.
My experiments showed that the longer and more complex the path you pass to MapPath, the slower it gets. By replacing the MapPath call in my code with PhysicalApplicationPath, I improved the overall IO time in my app benchmarks by 10%.
Yes, it can be. I was surprised to find that it was increasing my total IO time by a substantial amount--more than 10%, as I said. Prefer using PhysicalApplicationPath if at all possible.
Server.PhysicalApplicationPath is a gem that can really help your ASP.NET application function more precisely and faster. It is also self-documenting, because the function name describes its usage in your code.
Improving ASP.NET. Careful evaluation of every part of ASP.NET yields surprising results. The framework has many inefficiencies, but these are often caused by programmers not having insight into its internals.