JavaScript 扩展中的本机调试器对象 - 设计和测试注意事项

本主题介绍在 JavaScript 扩展中使用本机调试器对象的设计和测试注意事项。

本机调试器对象表示调试器环境的各种构造和行为。这些对象可以传递到 (，也可以在) JavaScript 扩展中获取，以操作调试器的状态。

有关调试器对象 JavaScript 扩展的信息，请参阅 JavaScript 扩展中的本机调试器对象。

有关使用 JavaScript 的一般信息，请参阅 JavaScript 调试器脚本。

调试器数据模型设计注意事项

设计原理

请考虑以下原则，使调试器扩展提供可发现、可查询和可编写脚本的信息。

避免采用不支持这些原则的方法。

不要将物品结构成一个平面的“厨房水槽”。有条理的层次结构允许用户浏览他们正在查找的信息，而无需事先知道他们正在查找的内容，并支持可发现性。
不要转换经典 dbgeng 扩展，只需将其移动到模型，同时仍输出原始文本屏幕。这不能与其他扩展组合，并且不能使用 LINQ 表达式查询。而是将数据拆分为单独的可查询字段。

命名规则

字段的大写应为 PascalCase。对于其他大小写中广为人知的名称（如 jQuery），可以考虑例外。
避免使用通常不会在 C++ 标识符中使用的特殊字符。例如，避免使用包含空格) 的“总长度” (或包含方括号) 的“[size]” (等名称。此约定允许从脚本语言（不允许这些字符作为标识符的一部分）更轻松地使用，也允许从命令窗口更轻松地使用。

组织和层次结构指南

不要扩展调试器命名空间的顶层。相反，应扩展调试器中的现有节点，以便信息显示在最相关的位置。
不要重复概念。如果要创建一个数据模型扩展，其中列出了有关调试器中已存在的概念的其他信息，请扩展现有信息，而不是尝试将其替换为新信息。换句话说，显示模块详细信息的扩展应扩展现有的 Module 对象，而不是创建新的模块列表。
自由浮动实用工具命令必须是 Debugger.Utility 命名空间的一部分。它们还应适当地 (子命名空间，例如 Debugger.Utility.Collections.FromListEntry)

向后兼容性和中断性变更

已发布的脚本不应破坏与依赖它的其他脚本的兼容性。例如，如果函数发布到模型，则它应尽可能保留在同一位置，并使用相同的参数。

不使用外部资源

扩展不得生成外部进程。外部进程可能会干扰调试器的行为，并且会在各种远程调试器方案中出现错误行为， (例如 dbgsrv remotes、ntsd remotes 和“ntsd -d remotes”)
扩展不得显示任何用户界面。显示用户界面元素在远程调试方案中的行为不正确，并可能会中断控制台调试方案。
扩展不得通过未记录的方法操作调试器引擎或调试器 UI。这会导致兼容性问题，并且在具有不同 UI 的调试器客户端上的行为不正确。
扩展只能通过记录的调试器 API 访问目标信息。对于许多远程方案，甚至某些跨安全边界的本地调试方案，尝试通过 win32 API 访问有关目标的信息会失败。

不使用 Dbgeng 特定功能

用作扩展的脚本不得尽可能依赖于特定于 dbgeng 的功能， (例如执行“经典”调试器扩展) 。脚本应在承载数据模型的任何调试器之上可用。