IIS7 doesn't monitor changes across symlinks

Question

I've used the mklink utility to create a symlink to a directory of web content. IIS7 doesn't "see" changes to any classic ASP files in this linked directory without issuing an iisreset. I've disabled caching and file changes are picked up on other static files (such as .html) but .asp files are ignored.

Answer 1

This is the answer your're looking for.

https://stackoverflow.com/questions/6698481/caching-problem-with-symlinks-on-iis-7-5

IIS doesn't know when a file over a symlink had been modified by visual studio. But you can tells iis to not cache local files in memory. Only use on developement environment... in production, you should recycle pool after an update if you use symlink.

Answer 2

This is either known or by design (take your pick of the euphemism for "it doesn't work like you'd think it would"). Under iis7 you should use virtual dirs to point to the same physical folder to achieve what you want.

Answer 3

The problem with this answer is that if you use a virtual directory to point to the physical location of content, then that content is at the directory level.

Suppose that you are a good developer and you use version control. Suppose that you have setup an integrated client/server environments where VSS is used on the server and the developers use Visual Studio on the clients. So, the developer checks out an asp file from VSS, makes a change and wants to test it on the client before checking it back in for integration testing on the server. You don't want to have the developer copy the file to wwwroot, so you have a virtual directory mapped to the VS Websites directory. Major problem arises due to web.config which controls the databases and report managers and all of the other MS crap that the site uses. The web.config in VSS correcty points to the server integration test environment where all developers changes are tested after unit test is complete on their clients. Well, iis does not have a search path for web.config that could override the web.config that is part of the VSS project that has been checked out into VS. This is where symlinks would be used. The wwwroot application directory would contain a local copy of web.config that points to the client development environment and have symlinks for the files that are under VSS control through VS.

This is so simple to do in linux and any other flavor of unix because symlinks have been around forever because the scenario and others like it that I described are so common.