第一个答案
In regards to an ASP.NET application I think of it like this:
Physical Path: OS path using drive/directory/file in which the actual app doesnt really use this path but if it did it would be mapped using a virtual path. A physical path is how the OS locates the resource/s ie: c:\inetpubwwwrootaspnetapp The actual app only cares about paths relative to its root directory.
Root Path: This would be the URI or URL at the root of your aspnetapp or ~/Home/Index with proper route config (Not to be confused with Unix Root Directory naming convention).
http://www.yardpenalty.com could actually be the location of this example's physical path in terms of an OS/NOS.
Virtual Path or Relative Virtual Path: The path that the application identifies or is identified by from its Web server.
For instance, in IIS (or OWIN) you may have a resource directory for your images in folder c:\inetpubftpimages but the developer maps this folder to the app like so... ~Images.
So think of this as the ability to create a relative path to resources identifiable by your app and its users while physically located elsewhere.
I would imagine that using a virtual path under a root application would be helpful in development when there are one or more projects that the developer wishes to give the appearance of a single application under a single domain.
Absolute Path: The entire path to a resource.
Let's say you have a link that takes you to a specific route like this: <a href="http://www.yardpenalty.com/home/about"> About</a>.
If this link was in the layout or master page a relative path <a href="~/home/about">About</a> would be cleaner.
There are instances when you need to hard code an absolute path but it is typically wiser to use relative paths especially when development involves migrations.
第二个答案
Making Sense of ASP.NET Paths
ASP.Net includes quite a plethora过剩 of properties to retrieve path information about the current request, control and application.
There's a ton of大量 information available about paths on the Request object, some of it appearing to overlap and some of it buried several levels down, and it can be confusing to find just the right path that you are looking for.
To keep things straight I thought it a good idea to summarize the path options along with descriptions and example paths.
I wrote a post about this a long time ago in 2004 and I find myself frequently going back to that page to quickly figure out which path I’m looking for in processing the current URL.
Apparently a lot of people must be doing the same, because the original post is the second most visited even to this date on this blog to the tune of nearly 500 hits per day.
So, I decided to update and expand a bit on the original post with a little more information and clarification based on the original comments.
Request Object Paths Available
Here's a list of the Path related properties on the Request object (and the Page object).
Assume a path like http://www.west-wind.com/webstore/admin/paths.aspx for the paths below where webstore is the name of the virtual.
1.ApplicationPath
Returns the web root-relative logical path to the virtual root of this app.
/webstore/
2.PhysicalApplicationPath
Returns local file system path of the virtual root for this app.
c:inetpubwwwrootwebstore
3.PhysicalPath
Returns the local file system path to the current script or path.
c:inetpubwwwrootwebstoreadminpaths.aspx
4.
Path
FilePath
CurrentExecutionFilePath
All of these return the full root relative logical path to the script page including path and scriptname.
CurrentExcecutionFilePath will return the ‘current’ request path after a Transfer/Execute call while FilePath will always return the original request’s path.
/webstore/admin/paths.aspx
5.AppRelativeCurrentExecutionFilePath
Returns an ASP.NET root relative virtual path to the script or path for the current request. If in a Transfer/Execute call the transferred Path is returned.
~/admin/paths.aspx
6.PathInfo
Returns any extra path following the script name.
If no extra path is provided returns the root-relative path (returns text in red below). string.Empty if no PathInfo is available.
/webstore/admin/paths.aspx/ExtraPathInfo
7.RawUrl
Returns the full root relative URL including querystring and extra path as a string.
/webstore/admin/paths.aspx?sku=wwhelp40
8.Url
Returns a fully qualified URL including querystring and extra path. Note this is a Uri instance rather than string.
http://www.west-wind.com/webstore/admin/paths.aspx?sku=wwhelp40
9.UrlReferrer
The fully qualified URL of the page that sent the request.
This is also a Uri instance and this value is null if the page was directly accessed by typing into the address bar or using an HttpClient based Referrer client Http header.
http://www.west-wind.com/webstore/default.aspx?Info
10.Control.TemplateSourceDirectory
Returns the logical path to the folder of the page, master or user control on which it is called.
This is useful if you need to know the path only to a Page or control from within the control. For non-file controls this returns the Page path.
/webstore/admin/
As you can see there’s a ton of information available there for each of the three common path formats:
- Physical Path
is an OS type path that points to a path or file on disk. - Logical Path
is a Web path that is relative to the Web server’s root. It includes the virtual plus the application relative path. - ~/ (Root-relative) Path
is an ASP.NET specific path that includes ~/ to indicate the virtual root Web path. ASP.NET can convert virtual paths into either logical paths using Control.ResolveUrl(), or physical paths using Server.MapPath(). Root relative paths are useful for specifying portable URLs that don’t rely on relative directory structures and very useful from within control or component code.
You should be able to get any necessary format from ASP.NET from just about any path or script using these mechanisms.
~/ Root Relative Paths and ResolveUrl() and ResolveClientUrl()
ASP.NET supports root-relative virtual path syntax in most of its URL properties in Web Forms.
So you can easily specify a root relative path in a control rather than a location relative path:
<asp:Image runat="server" ID="imgHelp" ImageUrl="~/images/help.gif" />
ASP.NET internally resolves this URL by using ResolveUrl("~/images/help.gif") to arrive at the root-relative URL of /webstore/images/help.gif which uses the Request.ApplicationPath as the basepath to replace the ~.
By convention any custom Web controls also should use ResolveUrl() on URL properties to provide the same functionality.
In your own code you can use Page.ResolveUrl() or Control.ResolveUrl() to accomplish the same thing:
string imgPath = this.ResolveUrl("~/images/help.gif");
imgHelp.ImageUrl = imgPath;
Unfortunately ResolveUrl() is limited to WebForm pages, so if you’re in an HttpHandler or Module it’s not available.
ASP.NET Mvc also has it’s own more generic version of ResolveUrl in Url.Decode:
<script src="<%= Url.Content("~/scripts/new.js") %>" type="text/javascript"></script>
which is part of the UrlHelper class. In ASP.NET MVC the above sort of syntax is actually even more crucial than in WebForms due to the fact that views are not referencing specific pages but rather are often path based which can lead to various variations on how a particular view is referenced.
In a Module or Handler code Control.ResolveUrl() unfortunately is not available which in retrospect seems like an odd design choice – URL resolution really should happen on a Request basis not as part of the Page framework. Luckily you can also rely on the static VirtualPathUtility class:
string path = VirtualPathUtility.ToAbsolute("~/admin/paths.aspx");
VirtualPathUtility also many other quite useful methods for dealing with paths and converting between the various kinds of paths supported. One thing to watch out for is that ToAbsolute() will throw an exception if a query string is provided and doesn’t work on fully qualified URLs. I wrote about this topic with a custom solution that works fully qualified URLs and query strings here (check comments for some interesting discussions too).
Similar to ResolveUrl() is ResolveClientUrl() which creates a fully qualified HTTP path that includes the protocol and domain name. It’s rare that this full resolution is needed but can be useful in some scenarios.
补充~/是用来访问web的根目录的