Frage

Wir begannen gerade in einem ungeraden Problem mit einem Filesystemwatcher läuft, wo der Anruf () zu entsorgen scheint zu hängen. Dies ist Code, der für eine Weile ohne Probleme gearbeitet hat, aber wir nur auf NET3.5 SP1 aktualisiert so versuche ich, um herauszufinden, ob jemand dieses Verhalten gesehen hat. Hier ist der Code, der die Filesystemwatcher erstellt:

if (this.fileWatcher == null)
{
   this.fileWatcher = new FileSystemWatcher();
}
this.fileWatcher.BeginInit();
this.fileWatcher.IncludeSubdirectories = true;
this.fileWatcher.Path = project.Directory;
this.fileWatcher.EnableRaisingEvents = true;
this.fileWatcher.NotifyFilter = NotifyFilters.Attributes;
this.fileWatcher.Changed += delegate(object s, FileSystemEventArgs args)
{
   FileWatcherFileChanged(args);
};
this.fileWatcher.EndInit();

Die Art und Weise dieser verwendet wird, um den Zustand Bild eines TreeNode Objekts zu aktualisieren (bereinigt leicht unternehmensspezifische Informationen zu entfernen):

private void FileWatcherFileChanged(FileSystemEventArgs args)
{
   if (this.TreeView != null)
   {
      if (this.TreeView.InvokeRequired)
      {
         FileWatcherFileChangedCallback d = new FileWatcherFileChangedCallback(FileWatcherFileChanged);
         this.TreeView.Invoke(d, new object[]
      {
         args
      });
      }
      else
      {
         switch (args.ChangeType)
         {
            case WatcherChangeTypes.Changed:
               if (String.CompareOrdinal(this.project.FullName, args.FullPath) == 0)
               {
                  this.StateImageKey = GetStateImageKey();
               }
               else
               {
                  projectItemTreeNode.StateImageKey = GetStateImageKey();
               }
               break;
         }
      }
   }
}

Gibt es etwas, uns fehlt oder ist dies ein anomoly von NET3.5 SP1?

War es hilfreich?

Lösung

Nur so ein Gedanke ... Jede Chance, es gibt ein Deadlock Problem hier?

Du nennst TreeView.Invoke, die ein blockierende Anruf. Wenn ein Dateisystem ändern gerade passiert, wie Sie klicken was auch immer Taste bewirkt, dass der FileSystemWatcher.Dispose () Aufruf, Ihre FileWatcherFileChanged Methode wird auf einem Hintergrund-Thread erhalten genannt und rufen TreeView.Invoke, die bis Ihre Form Thread blockiert die Invoke Anfrage bearbeiten . Allerdings würde das Formular Thread FileSystemWatcher.Dispose werden () aufgerufen, die wahrscheinlich nicht zurückkehren, bis alle anstehenden Änderungsanforderungen verarbeitet werden.

Versuchen Sie, die .Invoke zu .BeginInvoke verändern und sehen, ob das hilft. Das mag Punkt, den Sie in die richtige Richtung helfen.

Natürlich könnte es auch ein .NET 3.5SP1 Problem sein. Ich bin nur hier, basierend auf dem Code Spekulieren Sie zur Verfügung gestellt.

Andere Tipps

Scott haben wir gelegentlich Probleme mit Control.Invoke in .NET 2. Versuchen Umschalten auf Control.BeginInvoke gesehen und sehen, ob das hilft.

, dass Dadurch wird das Filesystemwatcher Gewinde erlauben sofort zurückzukehren. Ich vermute, Ihr Problem ist irgendwie, dass die Control.Invoke blockiert, so dass die Filesystemwatcher verursacht auf dispose einzufrieren.

Wir haben auch dieses Problem. Unsere Anwendung läuft auf .Net 2.0 wird aber von VS 2008 SP1 zusammengestellt. Ich habe .NET 3.5 SP1 als auch installiert. Ich habe keine Ahnung, warum dies geschieht entweder, es ist nicht wie ein Deadlock Problem auf unserer Seite sieht wie keine andere Threads an dieser Stelle ausgeführt werden (es ist während der Anwendung Shutdown).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top