A current problem with DNN is that the new ASP.NET 2.0 model will restart the process if the file system changes - to prevent pages from being served from the cashe if they no longer exist. This is a problem with DNN and I don't believe that it has been solved. There have been two workarounds mentioned:
The first solution is to disable the File Change Notifications - but this breaks the automatic compiler for when source code changes... not many people would want to use this.
The second soluiton is to use directory junctions to create a directory that is invisible to the eyes of the FCN engine. (see http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx)
The problem with both of these solutions is that neither system can be easily implemented by a hosting provider because admin permissions are needed to make changes.
I would like to suggest a third solution:
Currently, portal files can be stored in the _portals directory, and also in the database - right? (i haven't actually used this yet - but I am going to start looking into it). What if DNN was rearchitected to allow for a "Allow database portal file storage only" option that made it so that the _portals directory didn't even exist anymore - it was all just virtually created from binary files stored in the DNN database (this would be great for webfarming as well).
One downside of this is that you couldn't quickly edit the file structure or copy files in... Everything would need to be done through the DNN interface. Perhaps an FTP or SFTP server could be built that would allow access to this file system...
This may be way too much work; but this particular problem is very pressing - and I haven't heard much that can be done about it unless we get microsoft on board to implement a folder exception list into the ASP.NET framework itself...
It would be interesting to start a brainstorming session about the positives and negatives of using the database to store all portal specific content files (there would be a cache engine as well, that would keep commonly accessed files from having to travel between the web server and data base server very often).
Ideas?