使用 Visual Studio 2005 SDK 而不是自动化的 Debugger::GetExpression 评估表达式
我正在考虑为 Visual Studio 2005 编写一个插件(或包,如果需要),它需要监视窗口类型功能——表达式的求值和类型的检查。自动化设施提供 Debugger::GetExpression
,这足够有用,但是信息 提供的有点粗糙。
从查看文档来看,这听起来像是 IDebugExpressionContext2
会更有用。有了其中之一 看起来好像我可以从表达式中获取更多信息——详细 有关类型和任何成员等的信息,而无需将所有内容都作为字符串传递。
我找不到任何实际获取 IDebugExpressionContext2
的方法, 尽管! IDebugProgramProvider2
看起来有点相关,因为我 可以从 IDebugProgramProvider2::GetProviderProcessData
开始并且 然后慢慢向下钻取,直到达到可以供应我的东西 表达式上下文——但我需要为此提供一个端口,它是 不清楚如何检索当前调试对应的端口 会议。 (即使我尝试了每个端口,也不清楚如何判断 哪个端口是正确的...)
我开始怀疑这根本不是受支持的用例,但幸运的是,我只是错过了一些非常明显的东西。
有人可以帮忙吗?
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provideDebugger::GetExpression
, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like anIDebugExpressionContext2
would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2
,
though! IDebugProgramProvider2
sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData
and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
通过使用
IDebugExpressionContext
,您最终将获得IDebugProperty
的实例。该接口由表达式评估器服务实现。这通常是特定于语言的服务。它旨在抽象出评估表达式的语言特定细节。它理解更高级别的命令,例如“评估”和检查。我认为您不会得到您正在寻找的东西,因为您无法通过这种方式获得任何类型的对象。几乎所有检查方法都以
String
形式返回结果。例如,您不会获得类型Int32
,而是获得字符串“int”。这使得型式检验几乎不可能。我不相信你正在尝试的是一个受支持的案例。当前进程中不存在正在评估的类型系统。它存在于被调试进程中并且相当难以访问。
By using
IDebugExpressionContext
you'll ultamitely end up getting ahold of an instance ofIDebugProperty
. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in
String
form. For example you won't get the typeInt32
but instead the string "int". This makes type inspection next to impossible.I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
您可以采取一些技巧来获取有关使用 Debugger::GetExpression 方法评估的变量类型的更多信息。
您可以评估“AppDomain.CurrentDomain.GetAssemblies()”以将所有程序集加载到调试程序中,并将它们缓存在加载项中。您可能还需要侦听加载到 AppDomain 上的新程序集。
然后,运行以下命令:
一旦获得 TypeFullName,您就可以在程序集缓存中搜索匹配的 System.Type,一旦获得,您就可以使用标准反射 API 深入研究它。
请注意,由于其“typeof”关键字,这仅适用于 C#。例如,您必须对 VB.Net 使用不同的关键字。
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.