.NET 4.0文件系統枚舉功能的奇怪之處

我剛剛讀了一頁"Whats new .NET Framework 4.0"。我聽不太懂的最後一段：.NET 4.0文件系統枚舉功能的奇怪之處

要在列舉的目錄或文件
創建一個自定義的方法（或Visual Basic功能）包含您的枚舉代碼刪除打開的句柄。

將MethodImplAttribute屬性與無內插選項一起應用於新方法。例如：

[MethodImplAttribute(MethodImplOptions.NoInlining)] Private void Enumerate()
包括以下幾個方法調用，您枚舉代碼後運行：
* The GC.Collect() method (no parameters). 
    * The GC.WaitForPendingFinalizers() method. 

爲什麼屬性NoInlining？內聯會造成什麼危害？

爲什麼不手動調用垃圾回收器，爲什麼不讓枚舉器首先實現IDisposable？我懷疑他們使用FindFirstFile（）/ FindNextFile（）API調用imlementation，因此如果枚舉完成，則必須在任何情況下調用FindClose（）。

編輯：

沒有任何人有一個想法，爲什麼NoInlining屬性建議的文章？

來源

2010-04-18 codymanix

哇。我並不希望在MSDN的建議中看到* * * – 2010-04-18 19:34:23

我很驚訝地看到這一點，但請注意文章中列出的特殊情況：「如果您運行的是Windows XP或更早版本，則刪除如果在枚舉的目錄或文件之一上存在打開的句柄，則枚舉之後的文件或目錄上的操作可能會失敗，如果發生這種情況，則必須引發垃圾回收來移除打開的句柄。 – 2010-04-18 19:44:51

@布萊恩 - 如果它只適用於XP我滿足...... ish。 – 2010-04-18 19:59:28

很奇怪。迭代器正確地實現了IDisposable，它調用FindClose（）。 AllDirectories選項可能是一個麻煩的來源，因爲FindFileFirst/Next只允許迭代單個目錄。但是我看到迭代器做正確的事情，它只在迭代目錄結構時保持單個句柄打開。

MSDN文章特別提到「如果在枚舉的目錄或文件之一上存在打開的句柄」。 FindFileFirst/Next不會使句柄處於打開狀態。但是，在枚舉時讀取文件的用戶代碼不夠用。「對文件或目錄的刪除操作」也是相關的，我認爲Vista中的行爲發生了變化。 DeleteFile（）可以成功，但文件不會真正消失，直到文件上的所有句柄都關閉。

我們需要有人自願和不是在XP上實現此代碼。我想我們會很快找到某人:)

來源

2010-04-18 20:36:31

.NET 4.0文件系統枚舉功能的奇怪之處

回答

相關問題