JavaScript 延伸模組中的原生偵錯工具物件 - 設計和測試考慮

本主題描述在 JavaScript 延伸模組中使用原生偵錯工具物件的設計和測試考慮。

原生偵錯工具物件代表偵錯工具環境的各種建構和行為。物件可以傳入 (，或在 javaScript 延伸模組) 取得，以操作偵錯工具的狀態。

如需偵錯工具物件 JavaScript 延伸模組的詳細資訊，請參閱 JavaScript 延伸模組中的原生偵錯工具物件。

如需使用 JavaScript 的一般資訊，請參閱 JavaScript 偵錯工具腳本。

偵錯工具資料模型設計考慮

設計原則

請考慮下列原則，讓您的偵錯工具延伸模組呈現可探索、可查詢和可編寫腳本的資訊。

請避免這些不支援這些原則的方法。

請勿將您的專案結構成單一一平面的「廚房接收器」。組織階層可讓使用者流覽他們尋找的資訊，而不需要事先瞭解他們尋找的內容，並支援可探索性。
請勿直接將傳統 dbgeng 延伸模組移至模型，同時仍輸出原始文字的螢幕。這無法與其他延伸模組組合，而且無法使用 LINQ 運算式進行查詢。相反地，將資料分成個別的可查詢欄位。

命名方針

欄位的大小寫應該是 PascalCase。另一個大小寫中廣為已知的名稱，例如 jQuery，可以考慮例外狀況。
避免使用通常不會在 C++ 識別碼中使用的特殊字元。例如，請避免使用名稱，例如包含空格) 的「Total Length」 (，或 (包含方括弧的「[size]」) 。此慣例可讓您更輕鬆地從指令碼語言取用這些字元做為識別碼的一部分，也可讓您更輕鬆地從命令視窗取用。

組織和階層指導方針

請勿擴充偵錯工具命名空間的最上層。相反地，您應該擴充偵錯工具中的現有節點，讓資訊顯示在最相關的位置。
請勿重複概念。如果您要建立資料模型延伸模組，其中列出偵錯工具中已存在之概念的其他資訊，請擴充現有的資訊，而不是嘗試以新資訊取代它。換句話說，顯示模組詳細資料的延伸模組應該擴充現有的 Module 物件，而不是建立新的模組清單。
免費浮動公用程式命令必須是 Debugger.Utility 命名空間的一部分。它們也應該適當地 (子命名空間，例如 Debugger.Utility.Collections.FromListEntry)

回溯相容性和重大變更

發行的腳本不應中斷與其他相依腳本的相容性。例如，如果函式發行至模型，則應該盡可能維持在相同的位置，且具有相同參數。

不使用外部資源

延伸模組不得繁衍外部進程。外部進程可能會干擾偵錯工具的行為，而且會在各種遠端偵錯程式案例中錯誤， (例如 dbgsrv remotes、ntsd remotes 和「ntsd -d remotes」)
延伸模組不得顯示任何使用者介面。顯示使用者介面元素在遠端偵錯案例上的行為不正確，而且可能會中斷主控台偵錯案例。
延伸模組不得透過未記載的方法操作偵錯工具引擎或偵錯工具 UI。這會導致相容性問題，而且在具有不同 UI 的偵錯工具用戶端上的行為不正確。
延伸模組只能透過記載的偵錯工具 API 來存取目標資訊。嘗試透過 win32 API 存取目標的相關資訊，在許多遠端案例中都會失敗，甚至某些跨安全性界限的本機偵錯案例。

不使用 Dbgeng 特定功能

任何可能 (例如執行「傳統」偵錯工具延伸模組) ，都不得依賴作為擴充功能的腳本。腳本應該可在裝載資料模型的任何偵錯工具之上使用。