Мы столкнулись с той же проблемой в Stack Overflow, поэтому мы создали StackExchange.Precompilation. Вы можете прочитать об этом в нашем объявлении в блоге, но вот некоторые кровавые технические подробности, поскольку мы, естественно, исследовали, почему aspnet_compiler.exe работает так медленно, прежде чем написать для него собственную замену.
aspnet_compiler.exe существует задолго до того, как asp .net-mvc и razor, и, конечно же, он поддерживает такие вещи, как пакетная компиляция через <compilation batch="true" />. Однако для того, чтобы представление было скомпилировано, сначала необходимо преобразовать шаблон CSHTML в C # (CodeDOM). К сожалению, это не компиляция как таковая, поэтому batch="true" к ней не применяется. (не-) По сути, просмотры обрабатываются последовательно, по одному за раз. И любые функции roslyn, которые вы добавляете поверх него, только замедляют его, поскольку в какой-то момент должно быть преобразование CodeDOM -> roslyn.
Вот хорошая трассировка стека того, что происходит перед пакетной компиляцией в aspnet_compiler.exe.
Обратите внимание на этот вызов AddBuildProvider (который вызывает GenerateCode) уже находится внутри двух foreach циклов. Я полагаю, что параметры batch="true" были эффективны только для ускорения компиляции App_Code в проектах веб-сайтов ...
Вот что впоследствии произошло с нашими временами сборки:
Я бы не рекомендовал отключать предварительную компиляцию всем, кто запускает приложение ASP.NET MVC в производственной среде.
- Наиболее очевидным аргументом в пользу этого является то, что он подтверждает, что вы просматриваете код. В противном случае вы обмениваете ошибки времени компиляции на сервере сборки на ошибки времени выполнения в производственной среде.
- Другой аргумент в пользу этого - производительность. Ваши представления должны быть скомпилированы в какой-то момент, и если этого не происходит во время компиляции, первые несколько пользователей, которые попадают на ваш сайт, должны снова подождать в рабочей среде.
person
m0sa♦
schedule
14.03.2016
