FileSystemWatcher .Net 3.5

Question

在Win服务处于活动状态10年后，从.NET 1.1切换到3.5，处理超过200万个文件。我有一个异步类，它使用FileSystemWatcher事件处理程序将图形打印到PDFPrinter，现在在它自己的STA线程上归档PDF文件。由于现有客户端应用程序方法允许以DateTime间隔创建所有缺少的PDF，所以PDF创建是异步的。

（1）如果事件处理程序在STA线程上分离，则服务将挂起。 （2）只有少数PDF在几秒钟内到达，它工作正常。将其增加到5个PDF文件，不可避免的是一个文件不会被归档。将其增加到15个PDF文件，其中一些文件不会被归档（所有这些都在测试平台中）。在移动文件之前，我检查它是否存在，需要2次成功检测（PDF打印机倾向于生成幻像文件创建事件）。我也检查文件的独占访问权限。更新：我在COM交互代码的不同部分中尝试了另一个STA线程创建方法（通过参数化类和方法），并且具有与不可靠性相同的问题（只有大约50％的线程完成）。

对于PDFs，我很想设置一个定时器来归档放弃的文件，但我们不清楚何时启动定时器，以避免多个定时器尝试执行相同的归档任务（并发问题会带来额外的危险） ;那种设计感觉有点像皮带和吊带（消极因素）。

这就是这样一个常见的范例，它不应该很难做出健壮的！寻求启发（1）并帮助使新的STA线程可靠完成（2）。

伪

Test bed user interface: 
    // Process 20 instrument raw data files in a loop 
    // For each file: 
    // 1-2 s to setup processing and retrieve metadata from database on each file 
    // (A) spin off STA worker thread 
    // call instrument vendor COM API to read data file 
    // setup FileSystemWatcher for PDF files 
    // create graphical image PDF 
    // handle PDF_Created in a shell that ... 
    // (B) spins off STA worker thread to 
    // archive the PDF 

Answer 1

作答（2）：我不得不添加代码以线性化或再同步的新的STA线程与旧MTA线程（例如，方框父线程，直到工作线程完成）。

thread.Join(); 

，在伪代码点（A）运作良好，但不能以点（B）我在那里仍然需要一些共享的字段变量被移动到线的参数（不是所有的PDF文件是的潜在原因创建）

我承认仍不理解为什么通过网络存档文件的FileSystemWatcher需要在STA线程上处理（问题（1））。