为什么在bin \ Debug中运行exe时,不会抛出跨线程操作exception

我正在debugging应用程序,并在代码中的某个地方,一个线程试图到达另一个线程创build的列表框。 在尝试访问列表框时,应用程序抛出一个“跨线程操作无效:控制” 列表框 “从一个线程访问,而不是在线程上创build的线程”。 但是,当我在bin \ Debug文件夹中运行此应用程序的输出时,我没有得到一个exception对话框,我可以看到列表框是从非所有者线程成功访问的,所以这使我认为这里有一个行为差异,而不仅仅是一个压制的例外。 我可以通过在form_load事件中的以下行来debugging这个exception

Control.CheckForIllegalCrossThreadCalls = false; 

但是这种不同的行为背后的原因是什么?

是的,只有在连接debugging器时才会检查。 这是必要的,因为有很多 .NET 1.x代码违反了这个规则。 这不是一个明显的。

更大的问题是,这样的代码逃脱了。 要么运气好,不要过多地考虑偶尔出现的绘画问题,或者考虑在应用程序僵持时放弃应用程序,并在每天一次可以接受的情况下重新启动应用程序。 因为程序员没有真正的希望没有诊断就发现问题。

微软很在意落后compat,即使它是错误compat。 该修复是非常好的,即使它有时是错误的(Show(owner)被检查时不应该)。 有时候会忽略检查它是否违反规则的框架中的代码。 当线程依赖是间接的时候会发生什么情况。 最常见的情况是更新工作线程中的数据绑定控件的数据源(首先解除绑定!),并使用监听SystemEvents.UserPreferenceChanged事件的控件(不要在第二个线程上创buildUI!)


作为参考,相关代码存在于Control类的静态构造函数中:

 static Control() { //... checkForIllegalCrossThreadCalls = Debugger.IsAttached; //... }