Каждый раз, когда я открываю Visual Studio, изменения FileSystemWatcher EnableRaisingEvent

Question

Я использую C# в Visual Studio 2010 с фреймворком 4.0.

В моем проекте, в двух разных формах, есть два FileSystemWatcher s со значением EnableRaisingEvent, установленным на false. Если я закрою Visual Studio, когда я его снова открою, я получу в FileSystemWatcher свойство EnableRaisingEvent, установленное на true.

В обоих моих форм в файле дизайнера есть следующий код:

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

Свойство EnableRaisingEvent не установлен, но по умолчанию false.

Любая идея, почему я получаю это странное поведение?

редактировать

Я последовал предложению Virtlink, добавив следующую строку кода:

this.fileSystemWatcher1.EnableRaisingEvents = false; 

Это, казалось, решить мою проблему, но через несколько дней (и некоторые открытия, закрытия и восстановление проекта, но без изменения fileSystemWatcher1) я нашел:

• в конструкторе , В свойствах fileSystemWatcher1, EnableRaisingEvents был установлен обратно true

• в коде, ранее добавлена ​​линия отсутствует

Я пытался двигаться в Visual Studio 2012 (все еще рамки 4.0) и Обходной путь исправил проблему еще на несколько дней. Затем я получил ту же ситуацию, что и в VS10.

Любая другая идея?

Answer 1

Это также происходит в Visual Studio 2012, и вам не нужно закрывать Visual Studio. Повторного открытия конструктора форм достаточно, чтобы получить свойство, которое должно быть установлено в True, как визуально в дизайнере, так и во время выполнения.

Это, кажется, ошибка в FileSystemWatcher.

Обходной путь, чтобы добавить эту строку в InitializeComponent в явном виде:

this.fileSystemWatcher1.EnableRaisingEvents = false; 

Если дизайнер не будет работать с, вы должны будете работать против его. Все, что вы положили в InitializeComponent, может быть перезаписано или удалено дизайнером, так как InitializeComponent - это территория дизайнера. Один из способов борьбы с этим - добавить строку справа после вызов InitializeComponent в конструкторе формы.

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

Это означает, что дизайнер будет не показать вам правильное значение для EnableRaisingEvents, но так как он не работает все, что хорошо в любом случае это не может быть такой большой проблемой. Помещение строки в конструктор гарантирует, что она не будет удалена дизайнером в любой момент в будущем.

Answer 2

Теперь я не ожидаю, что этот ответ будет принят, но здесь все равно. Я написал небольшую препроцессорную программу, которая читает и изменяет исходные файлы C# в проекте Visual Studio и делает некоторые интересные вещи, например, предоставление некоторых услуг локализации и вставку уникальных лог-токенов в мои записи ведения журнала. Эта препроцессорная программа вызывается целью BeforeBuild во всех моих файлах .csproj, поэтому она запускается как часть каждого компилятора.

В настоящее время я не играю файлы .Designer.cs, но я изменяю файлы .resx, и они имеют такую ​​же неудачную характеристику, что и под эгидой дизайнера Visual Studio, поэтому мои модификации отбрасываются всякий раз, когда я измените форму, но затем моя программа препроцессора просто повторно модифицирует файл .resx. Это была бы такая же процедура для повторной установки этого оператора для установки EnableRaisingEvents на false всякий раз, когда дизайнер Visual Studio отменил его.

Это будет использовать кувалду, чтобы установить на место кулак, но это сработает.

EDIT:

Для тех, кто делает рассматривает возможность реализации этого в качестве метода для решения той или подобные проблемы, этот поток содержит несколько советов о том, как сделать Visual Studio сосуществовать с препроцессором: How to get Visual Studio to reread source files after BeforeBuild processing?

Answer 3

Я иду с Virtlink предложения о добавлении нужной строки в коде, например:

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

Вот еще несколько причин, которые я смог найти, чтобы защитить, почему вы не должны NOT (НЕ) редактировать дизайнера .cs

Вы можете найти более подробную информацию от Herenvardo comment Here. Вот краткое изложение этого вопроса.

Редактирование файла .Designer.cs (или .Designer.vb в Visual Basic) никогда не рекомендуется, независимо от того, почему вы хотите его отредактировать; и это почти никогда не нужно. Есть две основные причины, почему редактирование этих файлов так нежелательны:

1. Среда IDE записывает эти файлы с очень жесткими конвенциями кодирования, и ожидает, что они следуют таким конвенциям (вещи, как расстояние и не табуляции поднимать вопросы, но все, что изменяет структуру файла или дерево синтаксиса кода, очень похоже на неприятные побочные эффекты).
2. IDE может перезаписывать ваши изменения во многих ситуациях, без , даже сообщая вам. В общем случае для файла формы или пользователя usercontrol файл перезаписывается всякий раз, когда вы делаете изменение от дизайнера . Для файлов настроек (у меня не слишком много практики с этими), я думаю, они переписаны при редактировании настроек из самой IDE (со страницы настроек свойств проекта). Самый простой способ быть уверенным в том, что IDE может изменить любой файл .designer в любое время по любой причине.Несмотря на то, что хорошо определяется, когда IDE будет писать каждый файл, может быть довольно сложно знать и помнить, когда и почему каждый файл может быть переделан, поэтому лучше безопаснее, чем извините.