I'm writing a solution where I use some configuration files that should be editable at runtime. I've been using FileSystemWatcher
for this purpose before and never had much issues with it but now it's causing a CTD on the 'rename' event.
This (useless) piece of code will recreate the problem in my setup:
private static int _s_renamed;
private static int _s_created;
private static int _s_errors;
private static void monitorConfiguration(string configRootFolder)
{
var fsw = new FileSystemWatcher(configRootFolder, ConfigFilePattern)
{
NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName,
IncludeSubdirectories = false
};
fsw.Renamed += (sender, args) => ++_s_renamed; // <-- ! CTD efter this one !
fsw.Created += (sender, args) => ++_s_created;
fsw.Error += (sender, args) => ++_s_errors;
fsw.EnableRaisingEvents = true;
}
The crash comes from FileSystemWatcher
it seems. If I set a breakpoint in the event handler for FileSystemWatcher.Renamed
it gets hit but the app crashes when I step out of it. If I set a breakpoint in the FileSystemWatcher.Created
event handler this does not happen.
Any suggestions?
EDIT 1: I'm running .NET 4 on a Windows 7 x64 (Ultimate) platform I have seen several discussions concerning this type of problems but all has been related to people trying to update UI stuff (which must be done from the main/UI thread) from the event handlers. That's why I just try to increment some counters in the experimental code.
To stop the watcher from reporting changes then set its EnableRaisingEvents property to False. If you've finished with it then Dispose it. Your problem is that you haven't retained a reference to any of the FileSystemWatchers you've created.
Nope, filesystemwatchers run on their own thread.
Use FileSystemWatcher to watch for changes in a specified directory. You can watch for changes in files and subdirectories of the specified directory. You can create a component to watch files on a local computer, a network drive, or a remote computer.
Just to clarify:
The problem here was I had more/older consumers of the FileSystemWatcher
elsewhere in my system and one of them caused an unhandled exception. The problem is the exception gets thrown in a completely different thread and caused the application to crasch to desktop. The timing fooled me into thinking it was my new consumer that somehow cause the isse but when I followed Chris Shain's advice (see comments in the question entry) to enable break on exceptions (msdn.microsoft.com/en-us/library/d14azbfh.aspx) I immediately found the real culprit.
I would have preferred to credit Chris with the solution but he never re-posted so here it is. Hopefully we've learned something.
Thanks everyone and happy coding
/Jonas
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With