ASP.NET nested masters pages with CompilationMode="Never", a recepie for disaster? Bug in ASP.NET?

Question

While working on a quite big web application project, I decided that it could gain a little bit of fresh air by marking some of the pages and controls with the CompilationMode="Never" @Page attribute. So far so good, working as expected and then it happened. A corner case scenario that I am going to explain behaved unexpectedly to put it nicely. This scenario is nested master pages.

A quick teaser before continuing. How deep nesting do you think you could go if you mark the top master page as CompilationMode="Always", and all others beneath it with CompilationMode="Never"? No, its not infinite, or some internal number that ASP.NET has. Its 2. Why? - I have no idea, and I was hoping some of you smart guys could enlighten me?

I have attached a project with 5 nested master pages to demonstrate what I am talking about: Nested Master Pages Web Application Test Project.

Another corner case that is working unexpectedly as well - if you have 5 nested master pages, change the second to have CompilationMode="Always" and all others to have CompilationMode="Never". You will notice that the 3rd master pages is being applied twice!

Please help me understand if something I am doing is incorrect, or confirm the issue.

ASP.NET Runtime Version: 2.0, .NET: 3.5

EDIT:

The project attached has all master pages set to CompilationMode="Never". The ASPX page displays as desired. Change the first master (Site.master) to have CompilationMode="Always" to see what I am talking about.

Answer 1

UPDATE (1/21/2010): Good news: after more investigation, it turns out that this issue was fixed in VS2010. The fix was made post Beta 2, so it will be part of the next public build. I don't have an exact date, but it should not be too far out.

---

Yes, I seem to recall this coming up before, and indeed some scenarios involving nester master pages and CompilationMode="Never" are broken.

Looking at an old mail thread, I think it only happens for certain combinations. It looks like it’s broken for (where NoCompile means compilationMode=never):

1. NoCompile Page / Compile Master / NoCompile Master
2. NoCompile Page / NoCompile Master / Compiled Master

At the time, we did not fix this because the fix was non trivial and the scenario is not common.

Note that when it comes to NoCompile pages, most of the benefit is using it for end node aspx pages, and not master pages. Generally, NoCompile pages run a bit slower than compiled pages. Their benefit is that they don't have a first time compile hit, and they use less memory. Also, they can be fully unloaded under memory pressure. That's why they make good sense when you have a super large number of end point pages (Sharepoint uses them). But on master pages (where most apps only have a small number shared by many pages), that benefit would be minimal. And of course you can't have code in NoCompile pages, which is the main reason that few people use them.

So the quick summary is: you're right, it's a bug! :) And the recommended workaround is to avoid CompilationMode=never for master pages.