Each time I open Visual Studio the FileSystemWatcher EnableRaisingEvent changes

Question

I'm using C# in Visual Studio 2010 with the framework 4.0.

In my project, in two different forms, there are two FileSystemWatchers with the property EnableRaisingEvent set to false. If I close Visual Studio, when I reopen it I get in both FileSystemWatcher the property EnableRaisingEvent set to true.

In both my forms in the designer file there is the following code:

private void InitializeComponent()
{
     this.components = new System.ComponentModel.Container();
     System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(Form1));
     this.fileSystemWatcher1 = new System.IO.FileSystemWatcher();
     ((System.ComponentModel.ISupportInitialize)(this.fileSystemWatcher1)).BeginInit();   
     this.SuspendLayout();

     this.fileSystemWatcher1.Filter = "my_filter";
     this.fileSystemWatcher1.NotifyFilter = System.IO.NotifyFilters.LastWrite;
     this.fileSystemWatcher1.SynchronizingObject = this;
     this.fileSystemWatcher1.Changed += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Changed);
}

The property EnableRaisingEvent is not set, but the default is false.

Any idea why I get this strange behaviour?

edit

I followed the Virtlink's suggestion, adding the following line of code:

this.fileSystemWatcher1.EnableRaisingEvents = false;

It seemed to solve my problem, but after a few days (and some opening, closing and rebuilding of the project, but without modifying the fileSystemWatcher1) I found:

• in the designer, in the properties of the fileSystemWatcher1, EnableRaisingEvents was set back to true

• in the code, the line previously added was missing

I tried moving to Visual Studio 2012 (still framework 4.0) and the workaround fixed the problem for some more days. Then I got the same situation as in VS10.

Any other idea?

Answer 1

It also happens in Visual Studio 2012, and you don't have to close Visual Studio. Reopening the form designer is enough to get the property to be set to True, both visually in the designer and at run-time.

It seems to be a bug in the FileSystemWatcher.

A workaround is to add this line to your InitializeComponent explicitly:

this.fileSystemWatcher1.EnableRaisingEvents = false;

If the designer will not work with you, you'll have to work against it. Anything you put in InitializeComponent might be overwritten or removed by the designer, as InitializeComponent is the designer's territory. One way to deal with this is to add the line right after the call to InitializeComponent in your form's constructor.

InitializeComponent();
this.fileSystemWatcher1.EnableRaisingEvents = false;

This means the designer will not show you the correct value for EnableRaisingEvents, but since it didn't work all that well anyway that might not be such a big problem. Putting the line in the constructor ensures it is not removed by the designer at any point in the future.

Answer 2

Now I don't expect this answer to be accepted, but here goes anyway. I've written a little pre-processor program that reads and modifies C# source files in a Visual Studio project and does some interesting things, like providing some localization services and inserting unique log tokens in my logging statements. This preprocessor program is invoked by the BeforeBuild target in all of my .csproj files, so it gets run as part of every compile.

I'm not currently fiddling with .Designer.cs files, but I am modifying .resx files, and they have the same unfortunate characteristic of being under the auspices of the Visual Studio designer, so my modifications get discarded whenever I change a form, but then my preprocessor program just re-modifies the .resx file. It would be the same procedure for reinserting that statement to set EnableRaisingEvents to false whenever Visual Studio designer has discarded it.

This would be using a sledgehammer to put a thumbtack in place, but it would work.

EDIT:

For anyone who does consider implementing this as a technique to solve this or similar problems, this thread contains a couple of tips on how to make Visual Studio co-exist with a preprocessor: How to get Visual Studio to reread source files after BeforeBuild processing?

Answer 3

I go with Virtlink suggestion on adding the required line in the code, example:

  public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            this.fileSystemWatcher1.EnableRaisingEvents = false;
        }
    }    

Here is some more reasons I could find out to defend on why you should NOT(NEVER) edit your designer.cs

You could find more information from Herenvardo comment Here . Here is a brief of it..

Editing a .Designer.cs (or .Designer.vb in Visual Basic) file is never advisable, no matter why you want to edit it; and it is almost never needed. There are two main reasons why editing those files is so unadvisable:

1. The IDE writes these files with very rigid coding conventions, and expects them to follow such conventions (stuff like spacing and tabbing won't raise issues, but anything that alters the structure of the file or the parse tree of the code is very likelly to have nasty side effects).
2. The IDE may overwrite your changes under many situations, without even telling you. In general, for a form's or a usercontrol's .designer file, the file is overwritten whenever you make a change from the designer. For settings files (I have not too much practice with these), I guess they are rewritten when you edit the settings from the IDE itself (from the project properties' settings page). The simplest way to be safe is to asume that the IDE may change any .designer file at any time, for any reason. Despite it is well defined when the IDE will write each file, it may be quite hard to know and remember when and why can each file be remade, so better safe than sorry.