Word VSTO 在运行时吞下异常而不进行调试？
将此代码放置在 ThisDocument_Startup 之外的 Word 文档级 VSTO 解决方案中的某个位置（创建带单击事件的功能区按钮）：
int zero = 0;
int divideByZero = 10 / zero;
启动而不调试 (Ctrl + F5)，结果：异常被吞掉，其余代码默默失败。
如果放置在 ThisDocument_Startup 中，异常将可见，但它不会出现在其他地方。 Microsoft 的 VSTO 论坛和 MSDN 文档似乎觉得应该使用 Try...Catch - 这对于已知的未知数来说并不是什么大问题。 那些未知的未知数又如何呢？
处理托管代码的未处理异常的所有常见方法似乎都不起作用，大概是因为 VSTO 将托管代码与 Office COM Interops 一起使用：
//These don't work
AppDomain.CurrentDomain.UnhandledException ...
System.Windows.Forms.Application.ThreadException ...
我读过有关对 VSTO 代码进行故障排除的帖子，这些帖子似乎总是导致将 Try.. .几乎捕获一切！
有没有更好的方法来处理已知和未知（现在是隐形和无声的！）故障？
Place this code somewhere in a Word document level VSTO solution outside of ThisDocument_Startup (create a ribbon button, with a click event):
int zero = 0;
int divideByZero = 10 / zero;
Start without debugging (Ctrl + F5), Result: Exception is swallowed, the rest of the code fails silently.
The exception will be visible if placed in ThisDocument_Startup, but it appears nowhere else. Microsoft's VSTO forums and the MSDN documentation seem to feel Try...Catch should be used - which is not a big deal for known unknowns. What about the unknown unknowns?
All the common ways of dealing with unhandled exceptions for managed code don't seem to work, presumably because of VSTO using managed code with Office COM Interops:
//These don't work
AppDomain.CurrentDomain.UnhandledException ...
System.Windows.Forms.Application.ThreadException ...
I've read posts about troubleshooting VSTO code that always seems to lead to placing Try...Catch around practically everything!
Is there any better way to handle known and unknown (now invisible and silent!) failures?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
其实很简单，在运行 Office 应用程序之前将环境变量 VSTO_SUPPRESSDISPLAYALERTS 设置为 0，然后 Office 在出现问题时将显示异常，并且不会在启动过程中终止您的加载项。
还有一个有用的 powershell 脚本，可以为您执行此类操作，并且在确定 VSTO 何时无法在 http://archive.msdn.microsoft.com/vstotroubleshooter
首先运行
vstotroubleshooter.ps1 setdbg，这将为您设置 VSTO_SUPPRESSDISPLAYALERTS 环境变量Actually it is quite easy, set the environmental variable VSTO_SUPPRESSDISPLAYALERTS to 0 before running the office application, then Office will display exceptions and not kill your add-in during startup when there are issues.
There is also a useful powershell script which will do this sort of stuff for you and is handy when figuring out when VSTO not working at http://archive.msdn.microsoft.com/vstotroubleshooter
Get started by running
vstotroubleshooter.ps1 setdbgwhich will setup the VSTO_SUPPRESSDISPLAYALERTS env variable for you我认为该问题仅与“加载项用户界面”周围的异常有关 - 这恰好是此处找到的直接设置（Word 2007）：
Word 选项＆gt; 高级> 一般> “显示加载项用户界面错误”
I think the problem is isolated only to exceptions around the "add-in user interface" - which happens to be a direct setting found here (Word 2007):
Word Options > Advanced > General > "Show add-in user interface errors"
我在 Word 中使用应用程序级加载项时遇到了同样的问题。
如果您通过使用 F5 从 Visual Studio 启动加载项来运行加载项，那么您将始终在 VS 中得到“未由用户代码处理”（例如 2008 SP1），除非：
您取消选中 Visual Studio 设置“Break”对于 CLR 异常，“当异常为 .. 用户未处理”时，或者
对于
您随意应用 [ System.Diagnostics.DebuggerNonUserCodeAttribute()] 注释。
一旦完成其中一项，UnhandledException/ThreadException 似乎就可以工作了。
I had the same issue with an application-level add-in in Word.
If you are running your add-in by launching it from Visual Studio with F5, then you'll always get "unhandled by user code" in VS (eg 2008 SP1), unless:
you uncheck the Visual Studio setting "Break when an exception is .. user-unhandled" for CLR exceptions, or
you liberally apply the [System.Diagnostics.DebuggerNonUserCodeAttribute()] annotation.
Once you've done one of these, UnhandledException/ThreadException seem to work.