为什么 UI 自动化客户端中捕获的异常会出现在自动化的 UI 中？
一点背景知识...
我正在开发一个 UI 自动化应用程序，它与 UI 上的控件随机交互。自动化的应用程序和 UI 都是 WPF 应用程序。我正在使用 UI 自动化辅助功能框架。有时，我会在应用程序中收到 ElementNotAvailableException，我会捕获并处理该异常。当使用 ANTS 7 分析我们的 UI 时，我注意到这些异常出现在 Gen 2 垃圾堆上。异常的新实例与我在应用程序中捕获异常的次数相匹配。
我已经使用 WinDBG 查看了 GCRoot、UIAutomation 页面，但没有找到关于为什么在自动化应用程序中出现捕获的异常的明确解释。当 UI 自动化时，这些对象不会被释放，甚至当我关闭自动化应用程序时，这些对象仍然存在。
有什么想法吗？
A little background...
I am developing a UI automation app that randomly interacts with controls on our UI. Both the app and the UI being automated are WPF applications. I am using the UI Automation accessibility framework. Occasionally I get an ElementNotAvailableException in my app which I catch and handle. When profiling our UI using ANTS 7, I have noticed these exceptions are showing up on the Gen 2 garbage heap. The new instances of the exception match the number of times I caught the exception in my app.
I have looked at the GCRoot using WinDBG, the UIAutomation pages, and I have not found a clear explanation as to why a caught exception is appearing in the app being automated. The objects are not released when the UI is being automated and even remain when I close my automation app.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在不确切知道它是如何实现的情况下，我们可以知道，为了让 UI 自动化完成它需要做的事情：
检测部分由基础设施组成，这些基础设施实际上被编译到 UI 中的所有类中框架或添加到框架中，如果您愿意的话，就上瘾了。它“感染”主机应用程序并在其中运行一个小型应用程序。
进程间通信部分需要在客户端和主机之间传递非图形信息，例如文本框的实际内容。这听起来很简单，但实际上调用了在两个进程之间注入和交换类型和值。
现在，当您将这两件事结合起来时，异常可以作为进程间通信的一部分进行交换，并且该异常可以由作为自动化框架的迷你应用程序保存作为参考，并且您可以对它如何进行推测性解释可能会发生。
就您而言，如果您足够好奇，或者有足够的动力（可能是由于错误），您可以使用各种工具继续深入研究这个问题。你有调试器、ILSpy、黑盒实验、堆工具等。这取决于你需要走多远。
Without knowing exactly how it is implemented, we can know that in order for UI automation to do what it does it needs to do:
The instrumentation part consists of infrastructure that is literally compiled into all of the classes in the UI framework or added to the framework, hooked if you will. It "infects" the host application and runs a mini-application inside it.
The interprocess communication part is needed to pass non-graphical information between the client and the host such as the actual contents of a text box. This sounds simple but invokes literally injecting and exchanging types and values between the two processes.
Now when you combine these two things, an exception could be exchanged as part of interprocess communication and that exception could be held as a reference by the mini-application that is the automation framework, and you have a speculative explanation for how it could happen.
In your case, if you are curious enough, or motivated enough (perhaps by a bug), you could keep drilling into this issue with various tools. You have the debugger, ILSpy, black-box experiments, heap tools, etc. It's up to you how far you need to go.