I am currently working on converting my Companies website from Classic ASP and ASP.NET 1.1 to ASP.NET 2.0. We originally started converting most of our Administrative products from Classic ASP to ASP.NET 1.1 and this went very smoothly and worked fine. The reason we chose the Administrative products first is that it was less risky as users would not be faced with any code that may be broken and it is easier to talk with our staff than it is with clients in relation to technical problems.
As soon as ASP.NET 2.0 was released we decided to convert from ASP.NET 1.1 to 2.0 and then continue the rest of the conversion in ASP.NET 2.0. Again, this was fine and everything was working smoothly. Now that we were more confident, we shipped a new product on our Website which was for use by our clients. This product is simply a Media Gallery where our clients can view photos and other media content of interest to them and uses some sophisticated searching mechanisms to make the product more unique. This is when problems started to arise as our staff upload images very frequently. We had in place a system whereby folders would be created for every "n" number of images to keep the number of files within a single folder to a reasonable amount. Once this product had been deployed and was being used more and more regularly, our Administrative users started getting session timeouts at irregular intervals and we simply didn't know what was causing the problem.
Originally we thought that it was to do with our refresher technique (the refresher simply keeps the session alive) but this seemed to be working fine. So I started doing some research (still believing the problem to be with session timeouts) and couldn't find anything that explained the problem. I did however find other people that had experienced the same problem but answers to their posts seemed rather vague. One thing that I did learn however from this research is that ASP.NET 2.0 uses a "File Change Notification" (FCN) technique to determine when files have changed and then re-compiles the changed files when they are next hit by a user and serves the previous file from it's cache to those users still using the original file. I thought that this was it, and looked at how I can overcome this problem, but after more research I found that ASP.NET 2.0 only restarts the application after 15 files have been changed (this can be modified in the machine.config file using the numRecompilesBeforeAppRestart setting) and this didn't really fit the problems that we were experiencing.
Now that I knew about the FCN I decided to implement some debugging techniques that would hopefully help me out in finding the real cause of the problem. The first thing I did was to add a small piece of code to the Global.Asax's Application_End event that would e-mail me each time the application restarted. Then I also used a program that would monitor the website directory for any changes and log them to a list box and text file. I used my FileSystemWatcher demo program from a FAQ I wrote awhile ago. When I received the first e-mail notifying me that the application had restarted, I used the date and time value I had put in the body of the e-mail and tried to match it to an entry in my monitoring program, and lo and behold, there was indeed an entry. However, the entry was a little confusing at first as it wasn't a file change, instead it was a folder that had been renamed. I left this going for a day and each e-mail I got back matched to entries in my monitoring program showing folders either being renamed or deleted. I then ran some tests on my development server and each time I created and then deleted a folder, my development server would restart the application. To make things worse, we use Macromedia Dreamweaver for Classic ASP and when synchronising files between the development server and the live server, Macromedia Dreamweaver creates a temporary folder, read's it's timestamp and then deletes the folder hence another application restart (it does this as it has no way of reading the timestamp on the server for synchronisation purposes). This certainly explained why the restarts were so irregular.
At least now I knew why it was happening, but I still didn't know how to fix it, until I stumbled on this blog entry by Todd Carter. It explains the problem in detail and also a workaround (not pretty but effective) using the Linkd command line utility to create an NTFS Junction folder. Apparently Junction folders do not alert the FCN to changes so you can create, rename and delete folders to your heart's content without having your application restart. I originally thought however that I would just create a Junction folder for the entire website folder, but alas, you can't do that as the application will still restart, instead, you need to create Junctions for each folder that you expect to change frequently, which probably won't be many and in my case ended up being four folders at the moment. The technique appears to work great as I haven't had an application restart for a few days now on a live server hit thousands of times a day.
Hope this information proves useful.