调试 Visual Studio 设计器错误的好方法
有没有好的方法可以调试 Visual Studio Designer 中的错误？
在我们的项目中，我们有大量的用户控件和许多复杂的表单。 对于复杂的情况，设计器经常抛出各种异常，这没有多大帮助，我想知道是否有一些好方法来找出出了问题。
语言是 C#，我们使用的是 Visual Studio 2005。
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
请参阅调试设计时控件（ MSDN）。
See Debugging Design-Time Controls (MSDN).
我已经能够通过运行 VS 的第二个实例来调试一些控制设计器问题，然后从第一个 VS 实例执行“调试 -> 附加到进程”并选择“devenv”。
您将在第一个 VS 实例中设置断点。 使用第二个实例加载设计器以使“设计器”代码运行。
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
我已经经历过很多次这种情况，这真的很痛苦。
首先，我建议尝试遵循设计者提供的堆栈跟踪，尽管我发现它通常只是列出一堆没有多大用处的内部内容。
如果这不起作用，请尝试编译并从那里确定异常。 你真的是盲目飞行，这就是问题所在。 然后，您可以尝试简单地运行代码并查看运行时引发的异常，这应该会为您提供更多信息。
最后的方法可能是从表单中删除所有非生成的代码，然后逐渐重新引入它以确定错误。
如果您使用自定义控件，如果之前的方法仍然导致错误，您也可以手动删除与自定义控件相关的生成代码。 然后，您可以以相同的方式重新逐步引入此步骤，以确定哪个自定义控件导致了问题，然后单独进行调试。
基本上据我所知，除了稍微解决一下问题之外，没有真正解决这个问题的方法！
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
这在 2005 年一直是一个痛苦的问题，在 2015 年仍然如此。断点通常不会命中，可能是因为程序集被影子复制或设计者的其他操作（？）。 您能做的最好的事情就是通过引入对 Debugger.Break() 的调用来手动中断。 您可以将其包装到编译器条件中，如下所示：
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to
Debugger.Break(). You may wrap it into a compiler conditional as so:每一个都是不同的，有时可能会很晦涩难懂。 作为第一步，我将执行以下操作：
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
我发现为什么有时断点没有被命中。 在“附加到进程”对话框中，“附加到：”类型必须为“选择...”。
当我更改为“托管 4.0、4.5”后，WinRT 应用程序的断点被命中。 来源：WinRT 中的设计器调试 。
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
您可以运行 VS 的第二个实例并将其附加到 VS 的第一个实例 (Ctrl+Alt+P)。 在第一个实例中设置断点，在第二个实例中运行设计器，断点将触发。 您可以单步执行代码，但“编辑并继续”将不起作用。
要使“编辑并继续”工作，请将控制库的调试选项设置为运行 VS，并将命令行参数作为解决方案文件名。 然后您只需设置断点并按 F5。 它将像用户代码一样进行调试！ 附带说明一下，您也可以通过 VS 和 Office 加载项执行此操作。
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
这对我的 Visual Studio 2022 有用：
更多详细信息：https://learn.microsoft.com/en-us/dotnet /desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8
This worked for me for Visual Studio 2022:
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8