ecktwo wrote
Note that the web app shutdown is not caused by the changes in the file system, it is because of the FileSystemWatcher's buffer overflow......sadly, what this means is that if the AppDomain is restarted, then there is a performance hit while the AppDomain is started up and pages are recompiled on their first hit. Furthermore, session state that is running In-Process is lost.
So is this fact or fiction?
It is a fact. Actually it is a major issue with ASP.NET 2.0 and DotNetNuke. I posted this in the benefactors forum, but I'll post it here to help clarify the issue...
When DotNetNuke 4.x File Manger simply deletes a folder, the entire application is restarted.
Synopsis
When folders within an ASP.NET 2.0 application are deleted by an ASP.NET application such as DotNetNuke (or added/modified/deleted by Windows Explorer) they restart the application. This causes:
This rather unexpected behavior is with ASP.NET 2.0 and may explain some of new issues with DNN 4.x.
ASP.NET 1.x typically restarted the AppDomain on changes to global.asax, web.config or the /bin folder. ASP.NET 2.0 uses File Change Notifications (FCN) to monitor all folders within the application root, not just the root and App_xxx folders.
Proof of Concept
Using DotNetNuke
1) Login as Admin/Host
2) Select Admin|Log Viewer
3) Note last entry and timestamp
4) Select Admin|File Manager
5) Enter new folder xxx123 and click the new folder icon
6) Select Admin|Log Viewer
7) Note last entry and timestamp
8) Select Admin|File Manager
9) Expand the folders and select xxx123 and click the delete folder icon
10) Select Admin|Log Viewer
11) Note new shutdown and startup events caused by folder deletion
Using Windows Explorer
1) Login as Admin/Host
2) Select Admin|Log
3) Note last entry and timestamp
4) Navigate Windows Explorer to
c:\inetpub\wwwroot\dotnetnuke4\portals (or equivalent)
5) Add a new folder to portals
6) Select Admin|Log Viewer in browser
7) Note shutdown and startup events caused by adding|renaming|deleting the folder
Workaround
The only known workaround at this time is to use directory junctions to avoid monitoring and restarting the AppDomain. This may or may not be possible as it requires user permissions outside of the application sandbox and only works with NTFS formatted drives. There is a way to disable FCN in IIS, but it defeats the purpose of intended behavior. At this time there is no known fix to revert to ASP.NET 1.x behavior.
References
ASP.NET v2.0 - AppDomain recycles, more common than before
http://weblogs.asp.net/owscott/archive/2006/02/21/438678.aspx
Deleting ASP.NET 2.0 Application Sub-Directories Shuts Down the AppDomain
http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx
NTFS junction points and 'Deleting ASP.NET 2.0 Application Sub-Directories Shuts Down the AppDomain'
http://owasp.net/blogs/dinis_cruz/archive/2005/12/08/274.aspx
FIX: ASP.NET 2.0-connected applications on a Web site may appear to stop responding
http://support.microsoft.com/kb/911272/en-us