Acabamos de empezar a ejecutar un problema extraño con un FileSystemWatcher donde la llamada a Dispose() parece estar colgando. Este es un código que ha estado funcionando sin problemas por un tiempo, pero acabamos de actualizar a .NET3.5 SP1, así que estoy tratando de averiguar si alguien más ha visto este comportamiento. Aquí está el código que crea el FileSystemWatcher:FileSystemWatcher Dispose call cuelga
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();
La forma en que esto se esté utilizando para actualizar la imagen del estado de un objeto TreeNode (ajustado ligeramente para eliminar la información específica de negocio):
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;
}
}
}
}
Es Hay algo que nos falta o es una anomoly de .NET3.5 SP1?
Si está utilizando un FileSystemWatcher, potencialmente está utilizando otro hilo; el subproceso FileSystemWatcher podría bloquearse al intentar invocar el subproceso de la interfaz de usuario. –