Ogni volta che apro Visual Studio, l'errore EnableRaisingEvent di FileSystemWatcher cambia

Question

Sto utilizzando C# in Visual Studio 2010 con il framework 4.0.

Nel mio progetto, in due diverse forme, ci sono due FileSystemWatcher s con la proprietà EnableRaisingEvent impostata su false. Se chiudo Visual Studio, quando lo riaprio ottengo entrambi in FileSystemWatcher la proprietà EnableRaisingEvent impostata su true.

In entrambe le mie forme nel file di progettazione c'è il seguente codice:

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); 
} 

La proprietà EnableRaisingEvent non è impostata, ma il valore predefinito è false.

Qualche idea del motivo per cui ho questo strano comportamento?

modificare

ho seguito il suggerimento del Virtlink, aggiungendo la seguente riga di codice:

this.fileSystemWatcher1.EnableRaisingEvents = false; 

Sembrava di risolvere il mio problema, ma dopo un paio di giorni (e qualche apertura, chiusura e la ricostruzione del progetto, ma senza modificare il fileSystemWatcher1) ho trovato:

• nella finestra di progettazione , Nelle proprietà del fileSystemWatcher1, EnableRaisingEvents è stato fissato di nuovo al true

• nel codice, la linea precedentemente aggiunto mancava

ho provato a spostare a Visual Studio 2012 (ancora Framework 4.0) e la soluzione alternativa risolto il problema per alcuni giorni. Poi ho avuto la stessa situazione di VS10.

Qualche altra idea?

Answer 1

Succede anche in Visual Studio 2012 e non è necessario chiudere Visual Studio. La riapertura del form designer è sufficiente per impostare la proprietà su True, sia visivamente nel designer che in fase di esecuzione.

Sembra un errore nello FileSystemWatcher.

Una soluzione è quella di aggiungere questa riga al vostro InitializeComponent esplicitamente:

this.fileSystemWatcher1.EnableRaisingEvents = false; 

Se il progettista non funziona con voi, dovrete lavorare contro essa. Tutto ciò che viene inserito in InitializeComponent potrebbe essere sovrascritto o rimosso dal designer, poiché InitializeComponent è il territorio del designer. Un modo per risolvere questo problema è aggiungere la riga alla linea la chiamata allo InitializeComponent nel costruttore del modulo.

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

Questo significa che il progettista sarà non vi mostrano il valore corretto per EnableRaisingEvents, ma dal momento che non ha funzionato tanto bene in ogni caso che potrebbe non essere un grosso problema. Mettere la linea nel costruttore assicura che non venga rimosso dal progettista in qualsiasi momento.

Answer 2

Ora non mi aspetto che questa risposta sia accettata, ma qui va comunque. Ho scritto un piccolo programma di pre-elaborazione che legge e modifica i file di origine C# in un progetto di Visual Studio e fa alcune cose interessanti, come la fornitura di alcuni servizi di localizzazione e l'inserimento di token di registro univoci nelle mie dichiarazioni di registrazione. Questo programma di preprocessore è invocato dal target BeforeBuild in tutti i miei file .csproj, quindi viene eseguito come parte di ogni compilazione.

Attualmente non sto manipolando file .Designer.cs, ma sto modificando i file .resx, e hanno la stessa sfortunata caratteristica di essere sotto l'egida del designer di Visual Studio, quindi le mie modifiche vengono scartate ogni volta che cambia un modulo, ma il mio programma di preprocessore modifica nuovamente il file .resx. Sarebbe la stessa procedura per reinserire tale istruzione per impostare EnableRaisingEvents su false ogni volta che il designer di Visual Studio lo ha scartato.

Questo sarebbe utilizzare una mazza per mettere una puntina sul posto, ma funzionerebbe.

EDIT:

Per chi fa considerare l'implementazione di questo come una tecnica per risolvere questo o problemi simili, questa discussione contiene un paio di consigli su come rendere Visual Studio coesistere con un preprocessore: How to get Visual Studio to reread source files after BeforeBuild processing?

Answer 3

vado con Virtlink suggerimento su aggiungendo la riga desiderata nel codice, ad esempio:

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

Ecco alcuni ulteriori motivi che ho trovato a difendere sul perché si dovrebbe NOT (MAI) modificare il progettista .cs

È possibile trovare ulteriori informazioni da Herenvardo commento Here. Ecco un breve di esso ..

La modifica di un file .Designer.cs (o .Designer.vb in Visual Basic) non è mai consigliabile, indipendentemente dal motivo per cui si desidera modificarla; e non è quasi mai necessario. Ci sono due ragioni principali per cui la modifica tali file è così sconsigliabile:

1. L'IDE scrive questi file con convenzioni di codifica molto rigide, e si aspetta di seguire tali convenzioni (roba come la spaziatura e la tabulazione non sollevare questioni, ma tutto ciò che altera la struttura del file o l'albero di analisi del codice è molto probabile che abbia effetti collaterali sgradevoli).
2. L'IDE può sovrascrivere le modifiche in molte situazioni, senza che ti dica nemmeno. In generale, nel file .designer di un modulo o di un controllo utente, il file viene sovrascritto ogni volta che si modifica dal progettista. Per i file di impostazioni (non ho molta pratica con questi), suppongo che vengano riscritti quando si modificano le impostazioni dall'IDE stesso (dalla pagina delle impostazioni delle proprietà del progetto). Il modo più semplice per essere sicuri è quello di sospettare che l'IDE possa modificare qualsiasi file .designer in qualsiasi momento, per qualsiasi motivo.Nonostante sia ben definito quando l'IDE scriverà ogni file, potrebbe essere piuttosto difficile per sapere e ricordare quando e perché ogni file può essere rifatto, quindi meglio sicuro che dispiaciuto.