Share via


Deleting ASP.NET 2.0 Application Sub-Directories Shuts Down the AppDomain

This issue seems to be coming up recently since ASP.NET 2.0 shipped; probably because this behavior has changed from previous versions. In previous versions ASP.NET did not care if you deleted sub-directories of the web application and it appears some folks actually depended on this behavior and now when upgrading to ASP.NET 2.0 are finding their AppDomains are restarting after deleted a sub-directory.

 

The problem stems from the fact we have changed what actions we taken when monitoring File Change Notifications (FCN) in ASP.NET 2.0. The change was made so that when you delete a directory, either through Explorer or within the VS designer, stale content would not continue to be served. For example, suppose an application has a Virtual Directory definition that points to c:\webRoot and you have a sub-directory c:\webRoot\someDir. When you deleted someDir the AppDomain will shutdown with ASP.NET 2.0 but not with ASP.NET 1.0 or 1.1. Note that upon the very first request to that application the AppDomain will restart again. 
 

ASP.NET 2.0 uses a FCN that monitors for changes to the application root and all changes under that directory. At the time of this writing there is no fix to the product to change or revert the FCN behavior. If you find you need to delete an application sub-directory you need to block this behavior using a Directory Junction.

 

Let’s extend the sample web application used previously, let’s suppose I want to be able to create and delete files and directories within a directory under my web application at c:\webRoot. For this sample I consider these files and directories my content so I will create a directory named content such as c:\webRoot\CONTENT. I then create another directory which is really where my content will be stored at c:\MyWebContent. This sample assumes my C: drive is formatted as NTFS. I now need to create a directory junction between c:\webroot\content and c:\mywebcontent by using a utility called linkd.exe. The Linkd.exe utility ships with the Windows Server 2003 Resource Kit and can be downloaded from here.

 

Linkd is a command line utility and takes only a couple of parameters. To create a directory junction for my sample I run the command as so:

Linkd c:\webroot\content c:\mywebcontent

I pass linkd the source and the destination directories. Once created the directory junction graphs the contents of c:\mywebcontent into c:\webroot\content. So when I manipulate directories and files from either c:\webroot\content or c:\mywebcontent these changes are not reported back to the FCN monitoring c:\webroot. If however I delete or modify any content directly under c:\webroot the FCN will pick up these changes and restart the AppDomain so I need to ensure the changes are occurring under my content folder.

 

File change notifications do not follow the directory junction on Windows 2003 Server and Windows XP. I have not tested with Windows 2000 and would be interested to hear from the community if anyone has given this a try on that OS version.

 

For more information on NTFS directory junctions please refer to the KB article:
How to create and manipulate NTFS junction points

Comments

  • Anonymous
    December 01, 2005
    This doesn't sound like a good solution. Not at all.

    A lot of people cannot do this, especially if they are using an external host. And although IIS 7 will allough more to be done through configuration, getting access to a machine like this is a non-option.

    I would suggest a feature reversion or a compromise if possible. This is too brute force.

  • Anonymous
    December 05, 2005
    Todd, thanks for this smart comment about (FCN) in ASP.NET 2.0. We are developing a nice utility (I-Load) and we had to try many different ideas before the right solution working with ASP.NET 2.0. Maybe in the next releases of the software, we will give the possibility to use your directory junction solution, too.
    Thanks again,
    Simone
  • Anonymous
    December 05, 2005
    Thanks for the article!

    I have just discovered this behavior after migrating our web application to ASP.NET 2.0 and it seems to be a critical issue for us. Linkd does not solve the problem as our customers run the application not only on NTFS systems.

    Is there a chance to obtain a hotfix in the nearest future? Any rumours / estimations how much time will it take to fix the issue?
  • Anonymous
    December 07, 2005
  1. So if a web app creates a folder programatically, does it still restart the app?
    I think so.

    2. You have metioned that .NET 2.0 uses "FCN", What if i upload a file into a folder, does the App restart?
    If it does i wouldn't be happy (i will test it tonight). Some sort of incluison/exclusion list in web.config would have been nice, instead of linkd.exe (Just to make deployment more a XCOPY deployment). Yes we can use MSBuild to script all these, but traditionally XCOPY and update web.config was only thing we have to do to deployment. If we could retain this feature it would be good.
  • Anonymous
    December 07, 2005
    I would much prefer to patch the .Net framework to stop this from hapenning than introducing a change to the OS.

    see my comment in http://owasp.net/blogs/dinis_cruz/archive/2005/12/08/274.aspx

  • Anonymous
    January 04, 2006
    Gleb,
    If you want to try to pursue a hotfix for this behavior please call into Microsoft ASP.NET support and open a new incident. Of course you are not going to be charged here. We can then try to work on a hotfix for this issue. The reason we did not make a hotfix previously was because the users that first reported this problem were satisfied with the workaround AND the code work required to get this to work as it did in 1.1 did have some risk. We never like to churn code if we do not have to.

    -Todd

  • Anonymous
    May 23, 2006

     A refresh button for asp.net pages [Via: pvanooijen ]
     ASP.NET 2.0 Fix That Everyone Needs [Via:...

  • Anonymous
    July 17, 2006
    I have some additional information regarding my post  the detailed the deleing of...

  • Anonymous
    July 17, 2006
    PingBack from http://microsoft.wagalulu.com/2006/07/17/updatedeleting-aspnet-20-application-sub-directories-shuts-down-the-appdomain/

  • Anonymous
    November 07, 2006
    I stumbled across a very interesting findyesterday morning and Todd Carter confirmed it by sending a

  • Anonymous
    February 26, 2007
    PingBack from http://applicationweb.info/?p=1303

  • Anonymous
    February 27, 2007
    PingBack from http://applicationweb.info/?p=1337

  • Anonymous
    February 27, 2007
    PingBack from http://applicationweb.info/?p=1353

  • Anonymous
    April 10, 2007
    Voici une question fréquente sur les différents forums ASP.NET ... Depuis le Framework 2.0, il s'est

  • Anonymous
    April 11, 2007
    PingBack from http://www.chrismay.org/2007/04/11/ASPNET+Process+Recycling+Too+Often.aspx

  • Anonymous
    August 21, 2007
    The comment has been removed

  • Anonymous
    August 21, 2007
    The comment has been removed

  • Anonymous
    September 05, 2007
    the california museum of science and industry

  • Anonymous
    November 01, 2007
    Perhaps one of the most loved and hated features of ASP.NET is the ability to detect file changes and

  • Anonymous
    March 09, 2008
    Deleting sub-directories (folders) in ASP.NET 2.0 restarts the AppDomain

  • Anonymous
    January 21, 2009
    PingBack from http://www.hilpers.it/2613261-system-io-directory-delete-e

  • Anonymous
    February 11, 2009
    也许你知道,修改站点的某些特定文件和目录会导致整个站点重启或者重新编译。也许你不注意,你不会知道删除或重命名站点下的任意目录,会导致整个站点重启。这个问题其实是很多Session丢失的根源,比如《关于...

  • Anonymous
    April 14, 2009
    I am currently working on converting my Companies website from Classic ASP and ASP.NET 1.1 to ASP.NET

  • Anonymous
    April 14, 2009
    I am currently working on converting my Companies website from Classic ASP and ASP.NET 1.1 to ASP.NET

  • Anonymous
    May 31, 2009
    PingBack from http://www.dbforums.com/asp/1643236-session-abandon-asp-net-closes-all-active-sessions.html#post6402414