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