ASP.NET вложенных мастер-страниц с CompilationMode = "Никогда", получателем на случай катастрофы? Ошибка в ASP.NET? - PullRequest
2 голосов
/ 18 января 2010

Работая над довольно крупным проектом веб-приложения, я решил, что он может немного подышать свежим воздухом, пометив некоторые страницы и элементы управления атрибутом CompilationMode = "Never" @Page. Пока все хорошо, работает, как ожидалось, и тогда это случилось. Сценарий в угловом случае, который я собираюсь объяснить, вел себя неожиданно, чтобы выразить это красиво. Этот сценарий является вложенными главными страницами.

Быстрый тизер, прежде чем продолжить. Как вы думаете, насколько глубокой будет вложенность, если пометить верхнюю главную страницу как CompilationMode = " Always ", а все остальные под ней с помощью CompilationMode = " Never"? Нет, это не бесконечно, или какой-то внутренний номер, который есть в ASP.NET. Его 2 . Зачем? - Понятия не имею, и я надеялся, что некоторые из вас, умные ребята, смогут меня просветить?

Я приложил проект с 5 вложенными главными страницами, чтобы продемонстрировать, о чем я говорю: Тестовый проект веб-приложения с вложенными главными страницами .

Еще один угловой случай, который также работает неожиданно - если у вас есть 5 вложенных главных страниц, замените второй на CompilationMode = "Always", а на все остальные на CompilationMode = "Never". Вы заметите, что 3-я главные страницы применяются дважды !

Пожалуйста, помогите мне понять, если что-то делаю неправильно, или подтвердите ошибку.

ASP.NET Runtime Версия: 2.0, .NET: 3.5

EDIT:

В прикрепленном проекте все главные страницы имеют значение CompilationMode = " Никогда ". Страница ASPX отображается по желанию. Измените первый мастер (Site.master), чтобы CompilationMode = "Always", чтобы увидеть, о чем я говорю.

1 Ответ

2 голосов
/ 18 января 2010

ОБНОВЛЕНИЕ (21.01.2010): Хорошая новость: после дополнительного расследования выясняется, что эта проблема была исправлена ​​в VS2010. Исправление было сделано после Beta 2, поэтому оно будет частью следующей публичной сборки. У меня нет точной даты, но она не должна быть слишком далекой.


Да, похоже, я вспоминал об этом раньше, и действительно некоторые сценарии, включающие мастер-страницы Нестера и CompilationMode = "Никогда", не работают.

Глядя на старую почтовую ветку, я думаю, что это происходит только для определенных комбинаций. Похоже, что он не работает (где NoCompile означает compilationMode = never):

  1. Страница NoCompile / Мастер компиляции / Мастер NoCompile
  2. NoCompile Page / NoCompile Master / Скомпилированный мастер

В то время мы не исправляли это, потому что исправление было нетривиальным и сценарий не распространен.

Обратите внимание, что когда речь идет о страницах NoCompile, большая часть преимуществ заключается в использовании его для страниц aspx конечного узла, а не для главных страниц. Обычно страницы NoCompile работают немного медленнее, чем скомпилированные страницы. Их преимущество в том, что у них нет первого попадания при компиляции, и они используют меньше памяти. Кроме того, они могут быть полностью выгружены под давлением памяти. Вот почему они имеют смысл, когда у вас очень большое количество конечных страниц (их использует Sharepoint). Но на главных страницах (где большинство приложений имеют небольшое количество общих страниц), это преимущество будет минимальным. И, конечно, вы не можете иметь код на страницах NoCompile, что является основной причиной, по которой их используют немногие.

Итак, краткое резюме: вы правы, это ошибка! :) И рекомендуемое решение - избегать CompilationMode = никогда для главных страниц.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...