Почему aspnet_compiler.exe такой медленный (и может ли он быть быстрее)?

Question

Во время процесса сборки мы запускаем aspnet_compiler.exe для наших веб-сайтов, чтобы убедиться, что все компоненты с поздней привязкой в ​​ASP.NET/MVC действительно собираются (я ничего не знаю о ASP.NET, но уверен, что это необходимо для предотвращения поиска сбои во время выполнения).

Наши сайты довольно большие по размеру, с несколькими сотнями страниц / просмотров / элементов управления / и т.д. однако время, которое кажется слишком большим в диапазоне 10–15 минут (для справки, это больше, чем требуется для компиляции всего решения с приблизительно 40 проектами, а мы только предварительно компилируем два проекта веб-сайта).

Я сомневаюсь, что проблема заключается в аппаратном обеспечении, так как я работаю на последнем четырехъядерном чипе Intel с 4 ГБ ОЗУ и жестким диском WD Velociraptor 10 000 об / мин. И часть того, что странно, заключается в том, что EXE, кажется, не использует много ресурсов ЦП (1-5%) и, похоже, также не выполняет слишком много операций ввода-вывода.

Так ... это известная проблема? Почему это так медленно? И есть ли способ ускорить его?

Примечание: Чтобы прояснить пару вопросов, о которых люди ответили, я не говорю о компиляции кода в Visual Studio. Мы уже используем проекты веб-приложений, и скорость их компиляции не является проблемой. Проблема заключается в предварительной компиляции сайта после , эти проекты уже скомпилированы ( см. Эту страницу MSDN для получения дополнительной информации ) как часть сценария сборки dev. Мы выполняем предварительную компиляцию на месте, а не копируем файлы в целевой каталог.

Answer 1

Переключение на компилятор Roslyn, скорее всего, значительно улучшит время прекомпиляции. Вот хорошая статья об этом: http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications.aspx.

В дополнение к этому, убедитесь, что пакетная компиляция включена, установив для атрибута партии значение true в элементе компиляции.

Answer 2

Проще говоря, aspnet_compiler использует то, что фактически является «глобальной блокировкой компилятора» всякий раз, когда он начинает предварительную компиляцию любой отдельной страницы ASPX; в основном разрешено только последовательно компилировать каждую страницу.

Для этого есть причины (хотя я лично с ними не согласен) - прежде всего, для обнаружения и предотвращения циклических ссылок, вызывающих бесконечный цикл сортировок, а также для обеспечения правильного построения всех зависимостей до компиляции требуемой страницы. они избегают многих «неприятных проблем с CS».

Однажды я начал писать версию «1006» с массивной разветвленностью, когда в прошлый раз работал в веб-компании, но был связан с «реальной работой» и никогда не заканчивал ее. Самая большая проблема - это страницы ASPX: материал MVC / Razor, из которого вы можете распараллеливать АД, но механизм синтаксического анализа / компиляции ASPX имеет глубину около 20 уровней внутренних и частных классов / методов.

Answer 3

1. Компилятор должен генерировать второй файл с выделенным кодом для каждой страницы .aspx, check
2. Во время компиляции aspnet_compiler.exe скопирует ВСЕ файлы веб-сайта в каталог вывода, включая css, js и images.

Вы получите лучшее время компиляции, используя проект веб-приложения вместо модели веб-сайта.

Answer 4

Только мои 2 цента.

Одной из вещей, значительно замедляющих прекомпиляцию представлений ASP.NET, является параметр командной строки -fixednames для aspnet_compiler.exe. Не используйте его , особенно если вы используете Razor / MVC.

При публикации приложения wep из Visual Studio обязательно выберите «Не объединять», а не выберите «создать отдельную сборку», потому что это вызывает глобальную блокировку и замедляет работу. 1011 *

Подробнее здесь https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx

Answer 5

У меня нет специальных советов для этого компилятора, но когда у меня возникают проблемы такого рода, я запускаю ProcMon, чтобы посмотреть, что происходит на компьютере, и запускаю Wireshark, чтобы убедиться, что это не так. затрачивая время на отключение сетевого доступа к давно забытому компьютеру, на который есть ссылка в каком-то ключе реестра или переменной среды.