Symbolic Links in Unix, Linux and derivatives are a very common and useful feature. Symbolic links in these Operating systems allow you to place links to folders or files (which can be called shortcuts also in Windows terminology) in another folder but they appear completely transparent during normal access, meaning the file and folder that was linked to another folder appears as a normal file or folder and you can perform operations on the symbolic link as if the referenced file/folder was actually present itself instead of the symbolic link.

However, Windows Shortcuts are not exactly similar. Windows shortcuts leave a .lnk file in the target folder. Although they allow you to access the referenced file/folder through the shortcut, they are not completely transparent like symbolic links are. To prove this, test these steps:

1. Create a Virtual Directory in IIS somewhere, let’s say you have mapped “http://localhost/mydir” to “C:\inetpub\wwwroot\mydir”.
2. You can now access files and folders under this directory through the url.
3. Place a folder shortcut to let’s say “C:\Test” to “C:\inetpub\wwwroot\mydir”. The shortcut would appear as “C:\inetpub\wwwroot\mydir\Test.lnk”.
4. Try accessing “http://localhost/mydir/Test” in the browser, you will see a resource not found error.
5. Now try accessing “http://localhost/mydir/Test.lnk”, you will again NOT be able to access the “C:\Test” contents through this url.

This is where Unix/Linux Symbolic links differ from Windows shortcuts. A similar approach in Unix/Linux by creating a symbolic link and using Apache as the web server, browsing to “http://localhost/mydir/Test” would have given you the contents of the “C:\Test” folder or the default document rendered if one existed in that folder (obviously Unix file-system paths look different, but that does not affect the concept we are discussing).

My impression till recently was such a transparent facility provided by Symbolic links did not existed in windows, only to be proved wrong a few days earlier.

I was working on as ASP.NET application, where the primary application was a WAP project. It was dependent upon several library projects which were scattered all around on disk, some even on different drives. I had written a build script for the WAP project that copied the library projects (together with their resources which included javascript files also) to a sub-folder under the WAP project.

The whole process was painful. Copying resources which included tens of images was time-consuming and wasted productivity on each build. This was true even if a javascript file was changed in the dependent library projects.

I became so fed up with the build process, and wondered if some sort of symbolic links in the main WAP project to the other library projects would be possible. Obviously shortcuts were not an option as pointed out above (they would not allow browsing to the target folders as in the example above).

Some furious searching threw up a term called Junction in Windows. My initial instinct was to ignore it and move-on with other search results, as the term looked unrelated to what I was looking for. Still, I clicked that search result to go to this MSDN page. And what I read there made me think if I knew Windows at all after all these years.

I mean how come could I have not encountered this concept earlier. Windows Junctions/Hard links work exactly like Unix/Linux symbolic links, in that they allow you to transparently reference folders/files from other folders, so transparently that even IIS would not notice the difference, and a Junction point (aka a shortcut to another folder) under an IIS virtual directory would appear as a normal folder to IIS and IIS would allow accessing the contents of the Junction point through the Virtual Directory.

Hmmm… its really strange how things you believe to know so well suddenly appear strange and unknown to you. Well, having seen this concept, I thought there would be an easy way to create Junction points in Windows, only to figure out that Windows does not provide any UI to create junction points (maybe the reason many people on Windows, including me have never heard of Junction points before).

You can create a Junction point in Windows only through the native CreateSymbolicLink method of Win32 API (more information here). This appeared another hassle to me, and as I was preparing to write a VC program, I encountered this excellent small utility on Technet from Mark Russinovich. The utility provided command-line for creating and removing junction points in Windows, just what the doctor ordered.

Armed with my new found knowledge of Windows Junction points and this utility, I created the desired 5-6 junction points inside the main WAP project to all the referenced library projects, and never had to build afterwards until a .NET file was changed. And even then, the build process was extremely streamlined as there was no longer a need to copy the resources images, scripts etc.) on each re-build.