ASP.NET嵌套主页与CompilationMode =“Never”，一个recepie的灾难？ ASP.NET中的错误？

Question

在处理一个相当大的Web应用程序项目时，我决定通过标记一些页面和控件来获得一点新鲜空气，其编辑模式为CompilationMode =“Never” @Page属性。到目前为止这么好，按预期工作，然后发生了。我将解释的一个角落案例出乎意料地表现得很好。这种情况是嵌套的母版页。

继续前的快速传情。如何深度嵌套你觉得如果你关口上方母版页为CompilationMode =“始终”你可以走了，和它下面的所有其他与CompilationMode =“决不”？不，它不是无限的，或者是ASP.NET所拥有的一些内部数字。它的。为什么？ - 我不知道，我希望你们中的一些聪明人能够启发我？

我已附加了一个项目，其中包含5个嵌套母版页，用于演示我在说的内容：Nested Master Pages Web Application Test Project。

出现意外的另一个角落案例 - 如果您有5个嵌套母版页，请更改第二个以使CompilationMode =“始终”，其他所有其他人的编译模式=“从不”。您会注意到第三张母版页正在应用两次！

请帮我理解我正在做的事情是不正确的，或者确认问题。

ASP.NET运行时版本：2.0，.NET 3.5

编辑：

连接该项目所有的母版页设置为CompilationMode = “决不”。 ASPX页面按需显示。将第一个主站点（Site.master）更改为CompilationMode =“Always”，以查看我在说什么。

Answer 1

更新（1/21/2010）：好消息：经过更多的调查，事实证明，这个问题已在VS2010中修复。修正是在Beta 2后发布的，所以它将成为下一个公共构建的一部分。我没有确切的日期，但它不应该太过分。

---

是的，我似乎记得在此之前来了，的确有些场景涉及巢母版页和CompilationMode =“从不”被打破。

看着一个旧的邮件线程，我认为它只发生在某些组合上。它看起来像它打破了（其中NoCompile意味着compilationMode =永不）：

1. NoCompile页/编译主/ NoCompile主
2. NoCompile页/ NoCompile主/编译主

当时，我们并没有解决这个问题，因为修复不是微不足道的，而且情况并不常见。

请注意，当涉及到NoCompile页面时，大部分好处是将它用于末端节点aspx页面，而不是master页面。通常，NoCompile页面运行速度比编译页面慢。他们的好处是他们没有第一次编译命中，而且他们使用更少的内存。此外，它们可以在内存压力下完全卸载。这就是为什么当你有超大量的终点页面时（Sharepoint使用它们），它们很有意义。但是在母版页（大多数应用程序只有很少的页面共享一个小号码）上，这个好处是很小的。当然，在NoCompile页面中不能有代码，这是少数人使用它们的主要原因。

所以快速总结是：你是对的，这是一个错误！ :)建议的解决方法是避免CompilationMode =从不为母版页。