推荐订阅源

Making sense of ASP.Net Paths

---

February 19, 2004 @ 2:06 pm

ASP.Net a plethora of properties to retrieve path information about the current request, control and application. To keep things straight I thought it'd be a good idea to summarize those options briefly along with describing some common scenarios of how they might be used.

Here's a list of the Path related properties on the Request object (and the Page object):

Request Property	Function and Example
ApplicationPath	Returns the a Web server relative path to your application root /WestwindWebStore/
PhysicalApplicationPath	Returns a local file system path to your application root D:"inetpub"wwwroot"WestWindWebStore"
PhysicalPath	Returns the full file system path to the currently executing script D:"inetpub"wwwroot"WestWindWebStore"Item.aspx
CurrentExecutionFilePath FilePath Path	In most situations all of these return the virtual path to the currently executing script relative to the Web Server root. /WestwindWebStore/item.aspx
PathInfo	Returns any extra path following the script name. Rarely used – this value is usually blank. /WestwindWebStore/item.aspx/ExtraPathInfo
RawUrl	Returns the application relative URL including querystring or pathinfo /WestwindWebStore/item.aspx?sku=WWHELP30
Url	Returns the fully qualified URL including domain and protocol http://www.west-wind.com/Webstore/item.aspx?sku=WWHELP30
Page.TemplateSourceDirectory Control.TemplateSourceDirectory	Returns the virtual path of the currently executing control (or page). Very useful if you need to know the location of your ASCX control instead of the location of the page. /WestwindWebStore/admin

Note though that there is nothing that returns to you just the name of the virtual path of the current page without the script name, which to me seems strange. I would expect Path to do this but instead you’ll have to strip of the script name:

string VirtualPath = Request.Path.Substring(0,Request.Path.LastIndexOf("/")+1 );

Between these settings you can get all the information you may need to figure out where you are at and to build new Url if necessary. If you need to build a URL completely from scratch you may need a few more: Server Variables:

Server Variable	Function and Example
SERVER_NAME	The name of the domain or IP address
SERVER_PORT	The port that the request runs under – if other than 80 you’ll have to build that into the URL
SERVER_PORT_SECURE	Determines whether https: was used

If you’re building a URL from scratch you might use something like this:

string Port = Request.ServerVariables["SERVER_PORT"];

if (Port == null || Port == "80" || Port == "443")

      Port = "";

else

      Port = ":" + Port;

string Protocol = Request.ServerVariables["SERVER_PORT_SECURE"];

if (Protocol == null || Protocol == "0")

      Protocol = "http://";

else

      Protocol = "https://";

// *** Figure out the base Url which points at the application's root

this.BasePath = Protocol + Request.ServerVariables["SERVER_NAME"] +

                            Port + Request.ApplicationPath;

From there you can add Request.QueryString etc. as needed. But in most situations it might just be easier to use the Request.Url and manipulate the string the way you need to to get the path. Watch out for the URL not always returning port information though!

Relative Paths and Server Controls

The most common use for those variables above is to get the application base path to create relative URLS. If you’ve ever built user controls I’m sure you will have found out the hassles that go with relative paths for images or stylesheets if you move the User or custom Server Control into a different directory. For components you always need to build off this base path and then append the relative path to links as necessary.

Note that ASP.Net’s internal controls all support the ~ as an Application base path designator whereever you can provide a link. For example in the Image Control you can say:

MyImage.ImageUrl = "~/images/stop.gif";

which will always load the image out of the application’s images directory regardless where the current page lives. If you create controls that require paths you should also always support this convention. It’s pretty easy to implement with code like this:

///

/// Fixes up URLs that include the ~ starting character and expanding
/// to a full server relative path

///

///

the URL to fix up

public static string FixupUrl(string Url)

{

      if (Url.StartsWith("~") )

            return  (HttpContext.Current.Request.ApplicationPath +
                    Url.Substring(1)).Replace("//","/");

      return Url;

}

You can also use Control.ResolveUrl() which returns a fully qualified URL from a partial or relative path.