TIMERS.TIMER VS THREADING.TIMER VS FILEWATCHER VERIFICATION
TIMERS.TIMER VS THREADING.TIMER VS FILEWATCHER WINDOWS

TIMERS.TIMER VS THREADING.TIMER VS FILEWATCHER VERIFICATION

The original version used a Timer object to trigger verification of the folder's existence. The article was written in VB.Net, so I had to convert it to C#, and I also made the following modification. The reasons are laid out in his article, but I'll summarize his description by saying that if the watched directory somehow becomes inaccessible (maybe it's on a remote machine, maybe it was deleted), the FileSystemWatcher object doesn't recover - at all. In that article, George created an extension of the FileSystemWatcher class that allows it to monitor the folder being watched to make sure it's available. While I was researching for this article, I stumbled across a CodeProject article by George Oakes, called Advanced FileSystemWatcher. Something Borrowed - The FileSystemWatcherEx Class You should now be able to pick and choose which events to handle, and when. Gone (I hope) are the days of multiple events that are fired when programs like Notepad create a file. The technique presented in this article is in the form of a wrapper class than manages these individual FileSystemWatcher objects and provides a handy interface and event mechanism that can be used to cherry-pick the filters you want to use. You can pretty much guess that trying to manage that many FileSystemWatcher objects in a form would be excruciatingly painful. I came to the realization that you would need up to NINE FileSystemWatcher objects to pull this off - one to handle all of the other ChangeTypes, and one for each of the eight NotifyFilter enumerators. The ChangeType property in the FileSystemEventArgs parameter for the event merely indicated whether the item in question was changed, deleted, created, or renamed, and there is no property indicating the applicable filter in the case of the Changed event. You could use one or more of these filters, but upon receiving the Changed event, there is no way to see whatДЇilter actually triggered the event. I found this particularly irritating since they provided eight notification filters to make the FileSystemWatcher send the Changed event. My primary issue is that the FileSystemWatcher allows you to be notified that a file in a folder has changed, but not precisely what change was made. It was then, that the thought occurred to me that these FileSystemWatcher problems have never really be addressed (that I could find).

A day or so ago, someone posted a question regarding a similar task, and I immediately suggested the same route I had taken. I became immediately aware of the shortcomings of the FileSystemWatcher class, and those shortcomings have always kind stuck to my brain.

TIMERS.TIMER VS THREADING.TIMER VS FILEWATCHER WINDOWS

One of my first official tasks as a DotNet programmer was to write a Windows Service which monitored a folder on a server for new files, processed those files, and then transferred them to another server (via FTP). He prefers to use for background tasks on a thread pool thread.View Part 2 of this article series. So that it would be only useful if you want a timer on a design surface. In his book ' CLR Via C#', Jeff Ritcher discourages using, this timer is derived from, allowing it to be used in design surface of Visual Studio. see this question: Thread-safe execution using and Monitor Re-entrancy of timer notifications, where your timer event can trigger and call you back a second time before you finish processing the first event. It's easy to write race conditions when you're using timers. Perhaps it is just same as asked in this question: Thread-safety of vs, or perhaps everyone just means that:

I'm not fully clear what the supposed 'not thread safe' issues with are. Net timer possible, (because you are happy figuring out your own threading/dispatching) then is as good as it gets in the framework. If your app has no UI, and you want the most light-weight and general-purpose. instead wraps a native message-only-HWND and uses Window Timers to raise events in that HWNDs message loop. is a that wraps a, and provides some additional features used for dispatching on a particular thread. It calls you back on a thread pool thread (from the worker pool). I don't believe that there is a difference between the two as it pertains to how small your intervals can be. The specific difference appears to be that is geared towards multithreaded applications and is therefore thread-safe via its SynchronizationObject property, whereas is ironically not thread-safe out-of-the-box.

NET Framework Class Library' - also available as a.

This article offers a fairly comprehensive explanation:

Timers.timer vs threading.timer vs filewatcher