workaround for FCN/directory delete bug

A

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
 
B

bruce barker

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

-- bruce (sqlwork.com)
 
A

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
 
A

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.
 
P

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

Andy Fish said:
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.




Andy Fish said:
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
 
A

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

Patrice said:
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

Andy Fish said:
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.




Andy Fish said:
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
 
P

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

Andy Fish said:
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

Patrice said:
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

Andy Fish said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top