Why is that absolute path for file doesn't work properly?

function OnSelectedFileOpened(s, e) {
    var path = '‪file:///192.168.1.132/erp/WorklogFiles/' + e.file.id;
    window.open(path, "_blank");
}

The URL is like this when i ran the app "http://localhost:63956/file://..." so the app considering that as relative path...

The URL have to be "file://..."

What's the problem with that code?

Ok, first you have to keep VERY much in mind the difference between the web server (IIS) dishing out web pages, and that of using the "file://" option in a browser.

So, if I have a web page, say an html one like this:

<input id="Button1" type="button" value="Click me"
       onclick="myjavatest(); return false;"
       
       />


    <script>
        function myjavatest() {

            document.location.href = "file://test/control.pdf";

        }
    </script>

    <h3>Or try as link</h3>
    <a></a>
    <a href="file://test/control.pdf">link text</a>

You note that modern browser (most, if not all of them) DOES NOT allow the above code.

In other words, the "file://" has been LONG AGO depreciated. And the reason is simple:

No one on planet Earth is going to adopt and risk using a browser that allows YOUR WEB site to mess around and muck with files ON MY COMPUTER!!!

As such, it is a massive security hole, and thus is NOT allowed.

However, most browsers will STILL allow the user to type into the URL the above file name. Note how I said type in. In other words, for legacy support (but not very much), then you the user can type in "file://" by hand.

However, as above shows, a href (link) or even trying to use JavaScript to set that URL using "file://" simply does not work, and it NOT allowed anymore due to security reasons. Your web site can't start opening files on MY computer, and use of the "file://" from code allows the browser without user interaction for some malicious site to start opening files on my computer. As noted, this is simply not allowed anymore.

Ok, now with above out of the way?

The next concept is how does IIS mapping to files in the web site work?

Well, working with the above example, I could place that pdf file in a folder that is part of the folders for the web site.

So, say I have the pdf file here:

Ok, so now that the file is on MY web site and NOT YOUR computer?

Then you are now free to build a web page with references to those files.

So, for example in that above content folder, I have a picture called autofil.jpg.

So, in some web page, I can show that picture with an image control, say like this:

And when I run the page, I get this:

But a user could also type in the URL directly to that jpg file, and type in this:

So, ANY file that is part of the root page, or folders in the site?

The web server can dish out a web page, or even a file if you type in the correct URL.

Note how the URL will be:

 "Base root" of site + folder + file name.

So, during development, you see "localhost:xxxxxx/FolderName/FileName

However, if you publish to some web hosting, then the local host part will be replaced with the web site name - but the rest of the path name will continue to work.

Ok, then what happens if I have my web server, and then say some big corporate server with a whole bunch of PDF documents for product information that you can download?

Well, since those folders on that "other" server are not a sub folder of the web site, then you can't have a simple http (web based) path name to those files for download, can you?

So, you have 2 choices:

You can add what is called a virtual folder to the web site.

IIS express does not have a GUI and setup menu, so it can be a real pain during development and testing. For a condensed explain, a virtual folder allows you to map other folders on your corporate network to say files on that document server which of course may well not be on the same server as the web server.

So, that mapping will look say like this:

//server-docs/products

And in side above, you might have folders with product number, and then inside those the pdfs.

So, with a virtual folder, then now URLs of your root/base site name can ALSO use the above path name. You might call that virtual folder "products"

And thus, URL's now map to

  "www.mysitename.com/Products/21343/product.pdf

So, behind the scenes, the above actually gets converted to an internal file path and name of

     //server-docs/products/213343/product.pdf.

So, keep in mind that your VB.NET or C# code behind?

They ALWAYS but ALWAYS but ALWAYS use a valid windows path name. Your code behind does use nor care about the server "mapping" to the web site.

Often, for reasons of security, you might only want users to see say their own PDF documents for products they purchased, or for general reasons of security, you may not want to risk and have the wild internet and public be able to type in a URL to load such files.

In that case, then you can use a database, or other means to present the list of files, but then use code behind to load + stream down the file as a download. This approach allows far greater security, since then no file URL's or mapping from the web site exists, or is even possible.

So, only folders from the root folder and sub folders of that site can be used by URL's. You can as noted introduce virtual folders to map out other folders that are not part of the root and sub folders of the site.

Or, you can use code behind, secure that folder, or move it outside of the site. As long as the code behind running has rights to those files and folders, then code behind can read and stream out those files to the end user.

So, use of the "file://" is an old legacy option. A number of older web sites did use that file:// even in hyper-links say for staff to get at a bunch of files and folders, but do so say from a web interface.

However, these days, the use of "file://" as a hyper link, or even attempting to set from code is not allowed anymore.

However, uses can still by hand type in to the URL, and use "file://", as most browsers still allow typing in of such URLs, but attempts to use "file://" from code or even the web server code is simply not allowed anymore for reasons of security.