workaround for FCN/directory delete bug

[Andy Fish]

hi,

I have come across the problem mentioned in this blog

http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx

it's basically the fact that in ASP.NET 2.0, the File Change Notification is
uses causes the application to unload every time a directory underneath the
webroot is deleted.

The bodge suggested as a work-around in the article (which involves messing
around with the file system) is not an option that is open to me.

Does anyone know whether a proper fix or workaround for this problem is
available? if not, the only thing I can think of is to delete only files at
runtime and then wait until application shutdown to clear the directory
tree.

Regards,

Andy

 

[bruce barker]

create an app_data folder in your site, which asp.net does not monitor.

-- bruce (sqlwork.com)

 

[Andy Fish]

Thanks Bruce,

From what I can see, files in the app_data folder are not served through
IIS. Files in the folder structure I am creating need to be visible to the
web browser, so that solution is no good for me.

Andy

 

[Andy Fish]

just found this:

https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=240686

and I have implemented Kritter's hack which works fine for me on XP and win
2003 - copied below FYI:

Entered by [By]Kritter on 23/07/2007

A dirty hack that works:
PropertyInfo p =
typeof(System.Web.HttpRuntime).GetProperty("FileChangesMonitor",
BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static);
object o = p.GetValue(null, null);
FieldInfo f = o.GetType().GetField("_dirMonSubdirs", BindingFlags.Instance |
BindingFlags.NonPublic | BindingFlags.IgnoreCase);
object monitor = f.GetValue(o);
MethodInfo m = monitor.GetType().GetMethod("StopMonitoring",
BindingFlags.Instance | BindingFlags.NonPublic);
m.Invoke(monitor, new object[] { });

This code will turn off monitoring from the root website directory, but
monitoring of Bin, App_Themes and other folders will still be operational,
so updated DLLs will still auto deploy.

 

[Patrice]

My personal preference is just to not store those files under my web site
structure :
- you can server files stored outside of your structure (using an ASPX page
or a handler that allows additionaly to control how it is accessed
especially if those files are not supposed to be served to everyone)
- you could also likely use a virtual folder

This keep your web application and its data apart...

--
Patrice

just found this:

https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=240686

and I have implemented Kritter's hack which works fine for me on XP and
win 2003 - copied below FYI:

Entered by [By]Kritter on 23/07/2007

A dirty hack that works:
PropertyInfo p =
typeof(System.Web.HttpRuntime).GetProperty("FileChangesMonitor",
BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static);
object o = p.GetValue(null, null);
FieldInfo f = o.GetType().GetField("_dirMonSubdirs", BindingFlags.Instance
| BindingFlags.NonPublic | BindingFlags.IgnoreCase);
object monitor = f.GetValue(o);
MethodInfo m = monitor.GetType().GetMethod("StopMonitoring",
BindingFlags.Instance | BindingFlags.NonPublic);
m.Invoke(monitor, new object[] { });

This code will turn off monitoring from the root website directory, but
monitoring of Bin, App_Themes and other folders will still be operational,
so updated DLLs will still auto deploy.

Thanks Bruce,

From what I can see, files in the app_data folder are not served through
IIS. Files in the folder structure I am creating need to be visible to
the web browser, so that solution is no good for me.

Andy

 

[Andy Fish]

for the most part that is exactly what I am doing

however, to serve optimized (linearized) pdfs properly is rather more
complicated because the browser requests chunks of the file with separate
HTTP requests, so for this case I decided the best solution was to make a
temporary copy of the PDF underneath the web root, then redirect the browser
to it. that way the optimized download works properly without lots of extra
code

Andy

My personal preference is just to not store those files under my web site
structure :
- you can server files stored outside of your structure (using an ASPX
page or a handler that allows additionaly to control how it is accessed
especially if those files are not supposed to be served to everyone)
- you could also likely use a virtual folder

This keep your web application and its data apart...

--
Patrice

just found this:

https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=240686

and I have implemented Kritter's hack which works fine for me on XP and
win 2003 - copied below FYI:

Entered by [By]Kritter on 23/07/2007

A dirty hack that works:
PropertyInfo p =
typeof(System.Web.HttpRuntime).GetProperty("FileChangesMonitor",
BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static);
object o = p.GetValue(null, null);
FieldInfo f = o.GetType().GetField("_dirMonSubdirs",
BindingFlags.Instance | BindingFlags.NonPublic |
BindingFlags.IgnoreCase);
object monitor = f.GetValue(o);
MethodInfo m = monitor.GetType().GetMethod("StopMonitoring",
BindingFlags.Instance | BindingFlags.NonPublic);
m.Invoke(monitor, new object[] { });

This code will turn off monitoring from the root website directory, but
monitoring of Bin, App_Themes and other folders will still be
operational, so updated DLLs will still auto deploy.

Thanks Bruce,

From what I can see, files in the app_data folder are not served through
IIS. Files in the folder structure I am creating need to be visible to
the web browser, so that solution is no good for me.

Andy

create an app_data folder in your site, which asp.net does not monitor.

-- bruce (sqlwork.com)


Andy Fish wrote:
hi,

I have come across the problem mentioned in this blog

http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx

it's basically the fact that in ASP.NET 2.0, the File Change
Notification is uses causes the application to unload every time a
directory underneath the webroot is deleted.

The bodge suggested as a work-around in the article (which involves
messing around with the file system) is not an option that is open to
me.

Does anyone know whether a proper fix or workaround for this problem
is available? if not, the only thing I can think of is to delete only
files at runtime and then wait until application shutdown to clear the
directory tree.

Regards,

Andy

 

[Patrice]

Good point.

In my particular case, it was more a library of misc documents so I served
anyway all files using an attachment disposition for consistency.

Plus I always use myself "save as" on third party site as I really dislike
this feature that makes generally the browser (at least IE) much less
responsive IMHO ;-)

It looks this is discussed here and there :
http://www.google.com/search?hl=en&q=pdf++download+aspnet+handler+accept+range

Interesting topic.

---
Patrice

for the most part that is exactly what I am doing

however, to serve optimized (linearized) pdfs properly is rather more
complicated because the browser requests chunks of the file with separate
HTTP requests, so for this case I decided the best solution was to make a
temporary copy of the PDF underneath the web root, then redirect the
browser to it. that way the optimized download works properly without lots
of extra code

Andy

My personal preference is just to not store those files under my web site
structure :
- you can server files stored outside of your structure (using an ASPX
page or a handler that allows additionaly to control how it is accessed
especially if those files are not supposed to be served to everyone)
- you could also likely use a virtual folder

This keep your web application and its data apart...

--
Patrice

just found this:

https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=240686

and I have implemented Kritter's hack which works fine for me on XP and
win 2003 - copied below FYI:

Entered by [By]Kritter on 23/07/2007

A dirty hack that works:
PropertyInfo p =
typeof(System.Web.HttpRuntime).GetProperty("FileChangesMonitor",
BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static);
object o = p.GetValue(null, null);
FieldInfo f = o.GetType().GetField("_dirMonSubdirs",
BindingFlags.Instance | BindingFlags.NonPublic |
BindingFlags.IgnoreCase);
object monitor = f.GetValue(o);
MethodInfo m = monitor.GetType().GetMethod("StopMonitoring",
BindingFlags.Instance | BindingFlags.NonPublic);
m.Invoke(monitor, new object[] { });

This code will turn off monitoring from the root website directory, but
monitoring of Bin, App_Themes and other folders will still be
operational, so updated DLLs will still auto deploy.




Thanks Bruce,

From what I can see, files in the app_data folder are not served
through IIS. Files in the folder structure I am creating need to be
visible to the web browser, so that solution is no good for me.

Andy

create an app_data folder in your site, which asp.net does not
monitor.

-- bruce (sqlwork.com)


Andy Fish wrote:
hi,

I have come across the problem mentioned in this blog

http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx

it's basically the fact that in ASP.NET 2.0, the File Change
Notification is uses causes the application to unload every time a
directory underneath the webroot is deleted.

The bodge suggested as a work-around in the article (which involves
messing around with the file system) is not an option that is open to
me.

Does anyone know whether a proper fix or workaround for this problem
is available? if not, the only thing I can think of is to delete only
files at runtime and then wait until application shutdown to clear
the directory tree.

Regards,

Andy