为什么方法中存在Lambda表达式时无法编辑并继续调试？
我在其他问题中看到过 Linq 查询语法编译为 Lambda。
那么，为什么当方法中有 Lambda 表达式时不能进行编辑并继续，而使用查询表示法则可以呢？
最令人愤怒的是，并且让我认真考虑改用查询符号到处，即使您的代码不在 Lambda 中，但同一方法中的其他地方有 Lambda，您也可以'编辑并继续！这就像给粗心的开发人员带来的无端痛苦！
I've seen it said in other questions that the Linq query syntax compiles to a Lambda.
So why can you not do edit-and-continue when there is a Lambda expression in the method, while with query notation you can?
What's most infuriating, and is seriously making me consider switching to using query notation everywhere, is that even if your code is not in the Lambda, but there's a Lambda somewhere else in the same method, you can't edit-and-continue! That's, like, gratuitous pain inflicted upon unwary developers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
编辑并继续能够“实时”更改方法实现，但不能更改类型中的字段。
Lambda 表达式（和匿名方法）在捕获变量时最终可能会创建自己的私有类型。更改 lambda 表达式可能会更改涉及的类型，这会中断编辑并继续。
听起来应该可以对不产生这种影响的代码进行更改，但我怀疑完全阻止它会更容易 - 这也意味着您不会开始 进行更改，然后发现更改进行到一半时被阻止。
（就我个人而言，我一开始就不是E&C的粉丝，所以我从来没有注意到它。）
Edit and continue is able to change method implementations "live", but not what fields are in types.
Lambda expressions (and anonymous methods) can end up creating their own private types when they capture variables. Changing the lambda expression can change the types involved, which would break edit and continue.
It sounds like it should be possible to make changes to the code which don't have this impact, but I suspect it's simply easier to prevent it entirely - which also means you don't start making changes and then find that you're prevented half way through your change.
(Personally I'm not a fan of E&C in the first place, so I've never noticed it.)
我不确定，但我的猜测是，当涉及到的局部变量被提升到类时，弄清楚需要改变什么是很复杂的。我猜想，弄清楚哪些更改是安全的，哪些更改不安全，在这一点上被认为是复杂且容易出错的。 2010 年的工具主要关注线程和新的 UI——也许我们会在下一个版本中得到它。
I don't know for sure, but my guess is the complexity around figuring out what needs to change when there are local variables involved that are lifted to classes. I'm guessing that figuring out what changes would be safe and what wouldn't was deemed to complex and error-prone to get right at this point. The tooling in 2010 focused around threading and the new UI -- maybe we'll get it in the next version.
我不确定，但我认为这与编译器将形成闭包的 lambda 表达式转换为编译器生成的类的方式有关。可能没有（简单）方法来应用对编译代码所做的更改并保留当前状态。
I don't know it for sure, but I assume it has to do with the way the compiler converts lambda expressions forming closures into compiler generated classes. Probably there is no (easy) way to apply changes made to the compiled code and preserve the current state.