Using Web Paths and Tilde "~" in ASP.NET
~/ is not part of HTML, CSS, or JavaScript path systems.~/ is an artificial path resolution character only ASP.NET or 3rd party products use.~/ is a Web Server only path that gets translated to a new path by the code running on the server.~/ is a character that tells ASP.NET on the IIs Windows
Server to find the "application root" of your website.~/ resolves as a "Virtual Path" as it tells the server to find virtual or application root of a ASP.NET Web Application controlled by a given AppDomain on the server and resolve it from that new virtual root.~/ in most cases resolves to the web root of any website right right after the domain, no matter what page or subfolder you are in when the path is called. In almost all cases this resolves to /. So the two are the same in MOST cases unless you set up a Virtual Application on the server.~/ is really only useful when your website uses one or more Virtual Applications in a web server like IIs. These are artificial sub-applications under your web domain that add a new folder or path under a web root that do not truly exist but represent separate applications and processes managed by the server. This often creates one or more virtual application folders under your domain in IIs which ASP.NET and IIs manage when running separate instances of your ASP.NET website under one domain. See below...- Microsoft .NET is now using
~/ in Routing Attribute paths. When used they start the path back at the web root as an absolute path, but also override all controller or other attribute paths.
VIRTUAL WEB APPLICATIONS
In the old days, we used to create Virtual Applications in IIs Web Server to create two more web paths in order to isolate one or more web 'experiences' using the same domain. Each Virtual Path might be a "ghost" path that points back to the web root but creates an additional ghost folder under the web root. In many cases, that new virtual path pointed to a physical folder separate from the normal web path or even to computer hard drive path or mapping. ASP.NET with the right permission then ran web site code from there. The new virtual path shown to visitors of your web domain would then appear as part of the main site but run a second instance of your web application using a separate process run by ASP.NET (a separate AppPool or worker process).
~/ was then very useful in those cases. It was used in path resolution and easily mapped to the root of these new virtual application roots or paths created by the server, allowing you run multiple application under one website with no change to your paths in your ASP.NET code. The server-side code would then resolve the paths for you inside each virtual application with no changes to the code base.
~/ in those situations was extremely valuable as you no longer needed to manage multiple paths in your web app for each application if it ran in multiple virtual web applications under one website with different web roots. It could always find the new root in each application using ~/ rather than the true web root which was always http://example.com/
EXAMPLES
Most paths in ASP.NET using ~/ resolve to / in a normal website without virtual applications, and point all paths to the web root of the URL below. In most cases that is why ASP.NET ~/ is redundant. Just use /. Both point to the web root:
https://example.com/
However, if you added virtual directories to your domain, as this example below shows, ~/ inside each separate web application would resolve to two different web roots:
https://example.com/virtualapplication1/
https://example.com/virtualapplication2/
In the early days of ASP.NET, I always grabbed the application path using this code below stored in a global variable. This allowed me to fully control all paths from a relative application web root off the domain root or a virtual root no matter where my web application was moved to. But this path is what the ~/ replaced long ago. However, it still might be better as you can build paths from it dynamically on the server:
var myWebRoot = HttpContext.Current.Request.ApplicationPath;
My opinion is virtual applications like this are rarely used today as domains are cheap and subdomains are often used instead, like so:
https://app1.example.com/
https://app2.example.com/
All web paths should use absolute paths in every case possible /. The exception is CSS paths which are relative to the page source page or code calling them internally. Many say that means those absolute web paths break if you move them. But I argue, why would you need to reference the root for your website then suddenly change that? If you do, that should be managed on the server side and injected into your HTML and JavaScript, not the other way around.
Second of all, many Open Source, UNIX-based vendors are creating JavaScript API libraries that stumble around with dot paths which HTML and CSS do not support, like ./ or .
These are UNIX conventions that just mean to point to the local folder or the same folder the calling code is in. It's the same as NO PATH, so why use it? There are cases for their use, but the end result has zero affect on Web Paths. So I would avoid their use. The ONLY place they work in JavaScript reliably is in the new JavaScript Module in ECMAScript. But in proprietary API's like Google Angular, they are required.
For example these two image paths using UNIX local path conventions using ./ or . both fail in HTML and create missing image errors:
// These return broken image icons in browsers when using
// these unconventional UNIX local dot path conventions on the Web:
<img id="image1" src="./images/image1.png" />
<img id="image2" src="/images/.image2.png" />
So avoid all these deviant path system and stick with / absolute HTML paths and your code will always work for decades to come!
