Ускорение времени сборки в ASP.NET - PullRequest
10 голосов
/ 21 апреля 2009

В настоящее время я участвую в проекте ASP.NET, в котором задействовано около 40 проектов. Мы делаем все наши разработки в клонированных средах виртуальных ПК, поэтому у всех разработчиков одинаковые настройки. Это все хорошо, управлять зависимостями легко, однако создание решения идет ужасно медленно. Виртуальный ПК может использовать только один процессор, поэтому я использую только половину ресурсов своего компьютера.

От сборки до полной загрузки страницы уходит целых 3 минуты ... и с каждым днем ​​все хуже с ростом проектов. Исправление простых вещей начинает занимать много времени, и лично я все время разочаровываюсь, ожидая, что не могу по-настоящему работать, пока компилируется компьютер.

Есть ли способ распределить мою сборку по нескольким компьютерам, чтобы ускорить процесс сборки?

Может ли SSD заметно улучшить время сборки?

Есть ли другой способ ускорить сборку?

Примечание : я пытался предварительно скомпилировать статические зависимости с ngen , но позже прочитал, что ASP.NET не поддерживает ngen . Я использую Visual Studio 2008, и в виртуальной среде нет антивирусного программного обеспечения.

Ответы [ 10 ]

6 голосов
/ 25 ноября 2009

Вы можете значительно сократить время ожидания сборки в ASP.NET, выполнив следующие действия:

  • Используйте новый флаг "optimizeCompilations". Он скажет .NET не перестраивать весь проект только потому, что вы изменили один проект / dll. Если у вас есть 40 проектов, и вы не используете это, каждый раз, когда вы меняете простой метод в одном проекте, .NET будет пытаться скомпилировать все другие проекты и библиотеки. С новым флагом (плюс установка исправления) вы увидите значительное увеличение общей производительности во время разработки. Посмотрите этот пост в блоге с подробностями о том, как ускорить сборку с помощью флага optimizeCompilations: http://www.wagnerdanda.me/2009/11/optimizing-asp-net-build-time-with-dynamic-compilation-and-optimizecompilations/

Надеюсь, это поможет!

Вагнер Данда да Силва

4 голосов
/ 26 ноября 2009

А вот еще один совет, чтобы ускорить время сборки с ASP.NET:

  • Если у вас достаточно памяти, создайте RamDisk и направьте ваши временные файлы ASP.NET на этот оперативный диск. Посмотрите эту запись блога, чтобы узнать, как ускорить время сборки проектов ASP.NET с помощью RamDisk: http://www.wagnerdanda.me/2009/11/speeding-up-build-times-in-asp-net-with-ramdisk/

Надеюсь, это поможет!

Вагнер Данда да Силва

3 голосов
/ 21 апреля 2009

Вам нужно каждый раз перестраивать все 40 проектов?

Вы можете настроить то, что будет встроено в настройках Solution Configuration.

т.е. если вы вносите изменения только в свой проект WebUI, а остальные 39 проектов остаются без изменений, вы можете создать конфигурацию сборки, в которой будет перестроено только ваше веб-приложение.

  • Посмотрите на раскрывающуюся конфигурацию
  • Нажмите «Диспетчер конфигурации»
  • В раскрывающемся списке «Конфигурация активного решения» нажмите «Создать»
  • Создать новую конфигурацию, скопированную из конфигурации отладки
  • В новой конфигурации снимите флажки со всех сборок проектов, за исключением тех, которые вы внесли в
2 голосов
/ 21 апреля 2009

Не вкладывайте так много проектов в свои решения. Создавайте новый проект только тогда, когда код запускается в другом процессе или на другом компьютере. В большинстве случаев нет смысла создавать столько проектов. Количество проектов является наиболее значительным замедлением в msbuild.

2 голосов
/ 21 апреля 2009

У Скотта Гу есть довольно полезный пост об этом:

Совет / Трюк: оптимизация производительности сборки веб-проектов ASP.NET 2.0 с VS 2005

У Скотта также есть другая статья о скорости работы этого жесткого диска, которая также влияет на общую производительность Visual Studio:

Совет / хитрость: скорость жесткого диска и производительность Visual Studio

1 голос
/ 23 августа 2009

В нашей компании мы использовали ссылку на файл, поэтому нужно строить только измененные проекты, и в каждый момент времени в моем решении не более 10 проектов, в основном это 2 ~ 3.

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

Конечно, это не останавливает болезненную ссылку на сборку, но через некоторое время они становятся скорее неприятностью, чем проблемой.

1 голос
/ 21 апреля 2009

Вы также можете рассмотреть возможность перехода на рабочую станцию ​​VMware, которая использует несколько процессоров. В настоящее время я использую установку с двумя двухпроцессорными виртуальными машинами, и все четыре привыкли.

1 голос
/ 21 апреля 2009

У нас похожая ситуация, и я обнаружил, что наши виртуальные машины сильно ограничены, и поэтому, хотя каждая из них работала на одном процессоре, им не позволяли полностью использовать этот процессор. Мне удалось запустить 3 виртуальных машины на одном физическом устройстве, чтобы все работали на 100% быстрее.


Я бы также попытался сократить количество ваших проектов. Наши основные решения имеют 40 проектов, и я постепенно объединяю их и стараюсь, чтобы новые разработки вписывались в существующие проекты, где это возможно. Основными виновниками этого были веб-сервисы, каждый из которых изначально был создан в отдельном проекте. Теперь я добавляю все новые веб-сервисы в один проект и медленно перемещаю другие.

1 голос
/ 21 апреля 2009

Вы не упомянули свою версию Visual Studio, но если это 2005 год, возможно, вы захотите обновить его до 2008 года. В моем случае это сократило время сборки на крупном (более 30 проектов) решении.

Еще один вариант - предварительно собрать ряд библиотек, которые больше не меняются, и ссылаться на скомпилированные dll вместо проектов.

0 голосов
/ 21 апреля 2009

Вы пробовали настроить виртуальный ПК?

http://www.windowsnetworking.com/articles_tutorials/Tuning-Virtual-PC-Performance.html

Старая статья, но суть все еще верна.

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

Возможно, проблема не в Visual Studio, а в том, что компиляция требует больших ресурсов.

...