Оптимизация производительности сборки проекта веб-сайта ASP.NET?
Если Ваш язык поддерживает его, используйте названные параметры и сделайте как можно больше дополнительным (с разумными значениями по умолчанию).
5 ответов
Если простейшее решение с точки зрения исправлений состоит в том, чтобы сохранить структуру .cs как можно более похожей, я бы пошел с рекомендацией Андреаса перенести App_Code как минимум в 1 другой проект.
Скотт Гатри опубликовал несколько советов по скорости компиляции в VS 2005, вы не указали, какая у вас версия, но применимы те же советы по скорости. Второй раздел его сообщения относится к проектам веб-сайтов.
Еще один совет: если вы работаете со страницами, а не код в каталоге App_Code , есть сборка опция, которая может оказаться полезной . Перейдите в Свойства проекта > Сборка > Измените Перед запуском стартовой страницы с веб-сайта сборки на страницу сборки , это создаст только стартовую страницу, когда вы запустите отладчик. Я не уверен, что этот сценарий случается часто, но если большая часть вашей работы происходит на страницах, а не в App_Code , это сэкономит вам много времени на компиляцию.
App_Code должны быть собраны вместе , вам следует избегать наличия там вашего кода и т. д. Все, что может быть где-то еще, должно быть. Просто примечание: время компиляции, по крайней мере, при отладке, в веб-приложении обычно примерно в 30-50 раз быстрее. При этом вам нужно перекомпилировать все приложение при каждом изменении кода, поэтому есть недостатки ... но с изменениями пространства имен и тому подобным, я понимаю, что вам могут быть нанесены патчи напряжения.
Кроме того, имейте в виду, что при разделении код в другие проекты, помимо того, что он более простой с точки зрения компиляции, Visual Studio не нужно будет компилировать эти другие проекты зависимостей, если они не изменились. В настоящее время все идет честно, потому что все, что может измениться в вашем проекте, может повлиять на все остальное ... однако, если вы разделите его, Visual Studio будет компилировать другие ваши проекты только тогда, когда они изменятся или проект ссылка на них восстанавливается.
Вы должны хотя бы попытаться преобразовать его в веб-приложение, если только нет какой-либо политической причины не делать этого. . Это не так сложно, как кажется, самая большая проблема заключается в том, что всем вашим разработчикам, возможно, придется перенастроить свои решения.
Попробуйте переместить столько же кода в App_Code в разные проекты, поскольку они действительно не нуждаются в веб-сайт. Это должно хоть немного помочь.
Думаю, вашей самой большой проблемой будет огромное количество файлов. Я бы разделил веб-приложение на несколько (как минимум 2) проектов: ваш веб-проект и бизнес-уровень (или что-то в этом роде).
Мне кажется, что большинство этих файлов в коде приложения являются объектами или файлами, которые очень редко меняются, и, следовательно, в вашей ситуации не имеет особого смысла хранить их в своем веб-приложении.
Если вы все же решите пойти по этому пути, когда вы действительно внесете изменения в один из файлов в другом вашем проекте, у вас будет будьте очень осторожны при развертывании изменений, так как вам придется развертывать всю dll.
Вам следует попробовать новый флаг OptimizeCompilation, который мы недавно добавили.
<compilation optimizeCompilations="true">
Пожалуйста, прочтите мою запись в блоге , чтобы узнать, о чем она и где ее получить . Если вы не используете Win7 или VS2010, вам необходимо получить его с помощью исправления.
У нас возникла аналогичная проблема с нашим проектом, который построен таким образом, чтобы разрешить горячее добавление новые сайты партнеров с белыми ярлыками.
Самый простой способ, который мы нашли для ускорения времени сборки, - это уменьшить узкое место ввода-вывода, с которым зависает Visual Studio. Купите приличный SSD (мы используем диски Summit OCZ 60gb), и вы заметите, что время сборки значительно улучшилось.
Другой способ сэкономить время - уменьшить общее количество каталогов в вашем проекте. Для каждого нового каталога, с которым сталкивается Visual Studio, запускается новый экземпляр компилятора. Наличие как можно большего количества файлов в одном каталоге снижает эти затраты. (Чтобы получить структуру папок, которая делает проект поддерживаемым,