好的方法来debuggingVisual Studiodevise器错误

在Visual Studio Designer中debugging错误是否有很好的方法?

在我们的项目中,我们有大量的用户控件和许多复杂的表单。 对于复杂的devise者,devise者通常会抛出各种不利的例外,而且我想知道是否有一些很好的方法来弄清楚什么地方出了问题。

语言是C#,我们正在使用Visual Studio 2005。

请参阅debuggingdevise时控件 (MSDN)。

我已经能够通过运行VS的第二个实例来debugging一些控制devise器问题,然后从第一个VS实例执行“debugging – >附加到进程”并select“devenv”。

第一个VS实例是你设置断点的地方。 使用第二个实例加载devise器以使“devise器”代码运行。

2005年一直很痛苦,现在仍然是在2015年。断点通常不会受到影响,这可能是因为程序集被阴影复制或devise者(?)的东西。 最好的办法是通过调用Debugger.Break()来手动中断。 你可以把它换成一个编译器,如下所示:

 #if DEBUG System.Diagnostics.Debugger.Break(); #endif int line_to = break; // <- if a simple breakpoint here does not suffice 

我曾多次发生过这种情况,这是一个真正的痛苦。

首先,我会build议尝试跟随由devise者提供的堆栈跟踪,尽pipe我发现通常只列出一些内部使用不多的东西。

如果这不起作用,那么尝试编译并从那里确定exception。 你真的是盲目的,这是问题。 然后,您可以尝试简单地运行代码,并查看运行时引发了什么exception,这应该会提供更多信息。

最后一种方法可能是从表单中删除所有非生成的代码,并逐渐重新引入它来确定错误。

如果您正在使用自定义控件,则可以手动删除与自定义控件相关的生成代码,如果以前的方法仍然会导致错误。 然后,您可以用相同的方法逐步重新介绍这个问题,以确定哪个自定义控件导致问题,然后再单独debugging。

基本上,据我所知,这个问题没有真正的解决方法,除了打点一下!

我发现为什么有时候断点没有被击中。 在“ 附加到进程”对话框中,“附加到:”types必须是“select…”。

一旦我更改为“托pipe4.0,4.5 ”, WinRT应用程序的断点就会被击中。 来源: devise器在WinRT中debugging

每一个都是不同的,他们有时可能是模糊的。 作为第一步,我会做以下几点:

  • 使用源代码pipe理并经常保存。 出现devise器错误时,获取最近发生的受影响控件的所有更改列表,并testing每个更改,直到find罪魁祸首
  • 一定要检查相关控件的初始化例程。 很多时候,这些错误会发生,因为通过控件的默认构造函数调用一些错误或错误的依赖性(一个错误只能在VS中显示)

您可以运行VS的第二个实例并将其附加到VS的第一个实例(Ctrl + Alt + P)。 在第一个实例中设置断点,在第二个实例中运行devise器,断点将被触发。 您可以单步执行代码,但“编辑并继续”不起作用。

要编辑并继续工作,请设置控制库的debugging选项,以使用命令行参数作为解决scheme文件名来运行VS。 然后你可以简单地设置断点并按F5。 它将像用户代码一样进行debugging! 作为一个方面说明,你可以做VS和Office加载项。