註冊和散發屬性處理常式
本主題說明如何建立和註冊屬性處理常式，以使用 Windows 屬性系統。
本主題的組織方式如下：
註冊和散發屬性處理常式
實作屬性處理常式之後，必須註冊它，而且其副檔名必須與處理常式相關聯。 下列使用 .recipe 延伸模組的範例說明執行這項作業所需的登錄專案。
HKEY_CLASSES_ROOT
CLSID
{50d9450f-2a80-4f08-93b9-2eb526477d1a}
(Default) = Recipe Property Handler
ManualSafeSave [REG_DWORD] = 00000001
InProcServer32
(Default) = C:\\SDK\\PropertyHandlerSample\\bin\\RecipeHandlers.dll
ThreadingModel = Apartment
HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows
CurrentVersion
PropertySystem
PropertyHandlers
.recipe
(Default) = {50d9450f-2a80-4f08-93b9-2eb526477d1a}
特定檔案類型的屬性處理常式通常會與建立或操作該類型檔案的應用程式 () 一起散發。 不過，您也應該考慮讓屬性處理常式獨立于這些應用程式使用，以支援索引子使用屬性處理常式的伺服器案例中的檔案類型索引編制，但不需要其隨附的應用程式。 如果您為屬性處理常式建立獨立安裝套件，請確定它包含下列專案：
- 註冊和散發屬性處理常式主題中指定的屬性處理常式註冊詳細資料。
- 註冊您的檔案類型和任何必須安裝的架構檔案，讓用戶端能夠存取屬性處理常式的所有功能。
屬性處理常式的效能和可靠性考慮
特定電腦上的每個檔案都會叫用屬性處理常式。 它們通常會在下列情況下呼叫：
- 在編制檔案的索引期間。 這是在具有受限制許可權的隔離進程中完成。
- 在 Windows 檔案總管中存取檔案以讀取和寫入屬性值時。 這是在處理中完成的。
效能和可靠性的指導方針
使用者隨時可能會有數千個特定類型的檔案， (包括您電腦上的) ，而且可以隨時存取或修改任何或所有這些檔案。 因為經常叫用屬性處理常式來支援這些存取和修改作業，所以忙碌中屬性處理常式的效能和可靠性特性，高度並行的環境非常重要。
當您開發及測試屬性處理常式時，請記住下列指導方針。
屬性列舉
屬性處理常式在列舉其屬性時應該有非常快速的回應時間。 應避免大量計算屬性值、網路查閱或搜尋檔案本身以外的資源，以確保快速回應時間。
就地寫入屬性
可能的話，處理中型或大型檔案時， (數百 KB 或更大的) ，應排列檔案格式，以便讀取或寫入屬性值不需要從磁片讀取整個檔案。 即使需要搜尋檔案，它不應該完全讀取到記憶體中，因為這會使 Windows 檔案總管的工作集或 Windows 搜尋索引子嘗試存取或編制這些檔案的索引。 如需詳細資訊，請參閱 初始化屬性處理常式。
若要達成此目的，其中一個實用的技巧是使用額外的空間填補檔案的標頭，以便下次需要寫入屬性值時，就地寫入值，而不需要重寫整個檔案。 這需要 ManualSafeSave 功能。 這種方法牽涉到因為系統損毀或電源遺失 (而) 而進行中檔案寫入作業可能會中斷的一些額外風險，但因為屬性大小通常很小，因此這類中斷的機率同樣小，而且可透過就地屬性寫入實現的效能提升會被視為足以證明此額外風險。 即使如此，您也應該小心測試您的實作，以確保您的檔案不會在寫入作業過程中發生失敗時損毀。
最後，使用 ManualSafeSave 實作就地寫入屬性時，有時無法就地執行作業，而且必須重寫整個資料流程。 為了方便重寫，處理常式初始化期間所提供的資料流程支援 IDestinationStreamFactory 介面。 IDestinationStreamFactory介面可讓處理常式實作取得用於寫入的暫存資料流程;當所有寫入都完成且呼叫 IDestinationStreamFactory：：GetDestinationStream方法時，會使用此資料流程來完全取代原始檔案資料流程。 使用目的地資料流程時，應該將原始檔案資料流程視為唯讀，因為它會在呼叫 IDestinationStreamFactory：：GetDestinationStream 方法之後，由目的地資料流程取代。
選擇 COM 執行緒模型
若要將屬性處理常式的效率最大化，您應該指定它使用 COM 執行緒模型
Both。 這可讓您直接從 STA Apartment (Windows 檔案總管存取，例如) 和訊息傳輸代理程式 (MTA) Apartment (Windows 搜尋服務中的 SearchProtocolHost 程式，例如) ，避免在這些環境中封送處理的額外負荷。 為了達到執行緒模型的完整優點Both，您處理常式所依賴的任何服務也應該指定為Both，以避免對這些元件呼叫中的任何封送處理。 請檢查這些特定服務的檔，以確認它們是否使用此執行緒模型。屬性處理常式並行
屬性處理常式和 IPropertyStore 介面是專為序列而非平行存取所設計。 Windows 檔案總管、Windows 搜尋服務索引子，以及來自 Windows 程式碼基底的所有其他屬性處理常式調用都保證此使用方式。 協力廠商不應同時使用屬性處理常式，但無法保證此行為。 此外，即使呼叫模式必須是序列化，但是當物件透過 COM RPC 從遠端呼叫時，呼叫可能會因為索引子) 發生，而在不同的執行緒上 (。 因此，屬性處理常式實作必須支援在不同的執行緒上呼叫，在理想情況下，不應該同時呼叫時發生任何不良的影響。 由於預期的呼叫模式是序列的，因此使用重要區段的簡單實作應該足以符合大部分情況下的這些需求。 使用 TryEnterCriticalSection 函式來偵測並行呼叫並失敗，可避免封鎖並行呼叫。
檔案並行
屬性處理常式通常用於多個應用程式同時存取檔案的案例。 因此，處理常式和應用程式必須在開啟檔案時指定適當的共用模式來管理並行。 他們也需要注意其他應用程式所指定的存取權，以及管理不允許存取的情況。 如果所有取用者都指定了寬鬆的共用模式，讓其他人能夠同時存取檔案，但這麼做時，必須管理一致性問題。 在存取檔案的應用程式社群內容中，必須決定要使用的最適當共用模式。
檔案系統可讓應用程式以一種方式開啟檔案，以控制其他應用程式是否可以開啟檔案的方式。 共用模式可啟用讀取、寫入和刪除存取。 屬性系統支援這些共用模式的子集，如下表所述。
存取模式 共用模式 Write 拒絕其他讀取器和寫入器 寫入 (EnableShareDenyWrite) 啟用其他讀取器，拒絕其他寫入器 唯讀 (預設) 啟用其他讀取器，拒絕其他寫入器 唯讀 (EnableShareDenyNone) 啟用其他讀取器和寫入器 針對 寫入 (GPS_READWRITE) 開啟的屬性處理常式會拒絕其他讀取器和寫入器。 處理常式可以藉由指定
EnableShareDenyWrite旗標 (表示在其註冊中啟用讀取) ，來選擇啟用讀取器的行為。屬性處理常式會開啟以供 讀取 (GPS_DEFAULT) ，預設會啟用其他讀取器，但拒絕其他寫入器。 處理常式可以選擇在其註冊中指定
EnableShareDenyNone旗標來啟用其他寫入器。 這表示處理常式可以在處理常式讀取檔案時成功處理檔案內容變更的情況。如需旗標定義，請參閱 GETPROPERTYSTOREFLAGS。
相關主題