因此，每次我在不太正确的方法中编写了一个lambda表达式或匿名方法时，我都不得不重新编译并重新启动整个应用程序或单元测试框架，以对其进行修复。这是非常烦人的事情，并且最终我浪费了比最初使用这些构造更多的时间。即使Linq和lambdas是我最喜欢的C#功能之一，我也尽可能地远离它们，这是如此糟糕。
我想为什么会有这种技术原因，也许有人知道吗？此外，有人知道它是否会在VS2010中修复吗？
谢谢。
最佳答案
是的，为什么不能这样做是有很好的理由的。简单的原因是成本。在C#(或VB)中启用此功能的成本极高。
编辑lambda函数是一类ENC问题的特例，而当前的ENC(Edit'n'Continue)体系结构很难解决。即，ENC执行以下任一操作的方法非常困难:
第一个问题更多是逻辑约束，但也碰到了ENC体系结构中的两个限制。也就是说，产生一流的问题并不十分困难。麻烦的是在第二次编辑后生成了类。 ENC引擎必须不仅开始跟踪实时代码，而且还跟踪生成的类的符号表。通常情况并没有那么糟，但是当生成的类的形状基于使用它的上下文时，这将变得越来越困难(因为闭包，对于lambda来说就是这种情况)。更重要的是，您如何解决流程中已经存在的类实例之间的差异？
第二个问题是CLR ENC体系结构中的严格限制。 C#(或VB)无法解决此问题。
不幸的是，Lambda打击了这两个问题。简短的版本是ENC的lambda涉及现有类的很多突变(可能是由其他ENC生成的，也可能不是)。最大的问题在于解决新代码与当前流程空间中存在的现有闭包实例之间的差异。而且，lambda倾向于比其他代码更多地使用泛型，从而导致问题2。
这些细节非常繁琐，对于常规的SO答案也有些涉及。我考虑过就此主题写一篇冗长的博客文章。如果我能解决它，我会将其链接回该特定答案。