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））。