Use virtual directories to prevent AppDomain unload(s)

With ASP.NET, every site and even each virtual directory (that is, when it is marked as application) runs in its own AppDomain. In ASP.NET v1.x, there is an AppDomain unload when global.asax, web.config or anything related to the /bin folder is "touched" (updating / renaming files, creating /deleting directories).

In ASP.NET 2.0 this behaviour has changed, and now many more directories and files are monitored for File Change Notifications (FCN). The idea behind it, is that stale content doesn't remain in place after a significant change.

What this means is that every time you e.g. delete a directory within the webroot, the AppDomain is unloaded. And since Smartsite stores its objects and state within the AppDomain, these objects and state information are lost as well. So, upon the next request, Smartsite needs to start again, which takes a while and is not preferable.

The following list shows which files and directories are exactly monitored.

1. The application physical root path and all of its subdirectories are monitored for subdirectory name changes or deletions.
2. The bin, App_Code, App_WebReferences, App_GlobalResources and App_Browsers subdirectories of the application root folder are monitored for creation, deletion, renaming, ACL changes, changes to the last-write time and changes to the size. For each directory mentioned, when it exists, there will be a separate directory monitor. There will also be one additional directory monitor to let ASP.NET catch the creation of one of the above mentioned subfolders (unless all five of them already exists).
3. The machine.config and root web.config files (both located in %windir%\Microsoft.NET\Framework\v2.0.50727\Config) are monitored for changes.
4. The web.config of "parent" applications are monitored.
5. The application root itself is monitored for file creation, renaming, ACL changes, last-write time and changes to size, including the web.config and global.asax.
6. The hash.web file located in the "hash" subdirectory of the Temporary ASP.NET Files folder.
7. The web.config in any subdirectory of the application is monitored.
8. The App_LocalResources subdirectory of each virtual subdirectory is monitored for creation, deletion, renaming, ACL changes, changes to last-write time and changes to the size.

Furthermore, Smartsite iXperion adds its own directory monitor to catch changes to one of its configuration files (such as smartsite.config, smartsite.data.config and smartsite.security.config).

Virtual directories

Ultimately, in the end it comes down to the fact that you must be very careful to use the webroot or any of its subfolders as "working" directory. When you want to provide an upload directory, create an upload directory outside the webroot (e.g. within the system folder within the site) and create a virtual directory within IIS to this directory, so it is still accessible.

Also, in the past the Smartsite Manager did use by default the import and export subfolders within the webroot as source/target directory when using the Import and/or Export Wizard(s). Although this behaviour has been changed to use the import and export subfolders within the system folder whenever the user has access to it, it is still the user's choice where exported files should be stored or from which directory the Importer should read the files (and most likely the folder to which the user will upload the files to be imported).

It is therefore adviced to remove the import and export subfolders from within the webroot, make sure you have import and export subfolders within e.g. the system folder, and create virtual directories within IIS to both of them.

Furthermore, by restricting access to all non-virtual subfolders within the webroot using Smartsite's built-in File Security, you prevent users to make any file-changes etcetera which could otherwise cause an AppDomain unload.

Disabling one of the File Changes Monitor

Another option is to disable the File Changes Monitor which detects folder renaming and deletion of subfolders of the application root, since that is the most annoying monitor of them all.