Как настроить ASP.Net MVC для быстрой сборки

Question

Я хочу найти лучшую настройку для проектов ASP.Net MVC, чтобы получить самый быстрый процесс code-build-run в Visual Studio.

Как вы можете настроить свое решение так, чтобы оно достигало почти нулевого времени сборки для небольших постепенных изменений?

Если у вас есть тестовый проект с зависимостями от других проектов в вашем решении, сборка тестового проекта все равно будет обрабатывать другие проекты, даже если они не изменились.
Я не думаю, что это полностью перестраивает эти проекты, но, безусловно, обрабатывает их. При выполнении TDD вы хотите, чтобы время ваших небольших инкрементных изменений составляло время, близкое к нулю, а не задержку в 20 - 30 секунд.

В настоящее время мой подход состоит в том, чтобы ссылаться на dll зависимого проекта вместо ссылки на сам проект, но это побочный эффект, требующий от меня создания этих проектов независимо, если мне нужно внести изменения в них, а затем построить свой тестовый проект .

Один небольшой совет: если вы используете PostSharp, вы можете добавить символ условной компиляции SKIPPOSTSHARP, чтобы избежать перестройки аспектов в ваших проектах во время модульного тестирования. Это работает лучше всего, если вы создадите отдельную конфигурацию сборки для модульного тестирования.

Answer 1

Мне нравится Луковая архитектура .

В решении должно быть только ~ 3 проекта =>

• Основной
• Инфраструктура
• UI

Поместите еще 2 проекта (или 1 и используйте что-то вроде категорий nUnit для разделения тестов) =>

• UnitTests
• IntegrationTests

Трудно урезать больше. <= 5 проектов не плохо. И да - избегайте ссылок на проекты. </p>

Также может помочь выгрузка ненужных проектов через VS.

И самое главное - убедитесь, что ваш компьютер не забит. :)

---

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

---

Небольшой совет - вместо того, чтобы перестраивать все решение, перестраивайте только выбор (Инструменты => Параметры => Клавиатура => Build.RebuildSelection). Сопоставьте его с Ctrl + Shift + B. Оригинальная карта переназначается на Ctrl + Shift + Alt + B.

Answer 2

Вот как вы можете структурировать свои проекты в решении:

• YourApp.BusinessLogic: библиотека классов, содержащая контроллеры и другую логику (это может ссылаться на другие сборки)
• YourApp: веб-приложение ASP.NET MVC, ссылающееся на YourApp.BusinessLogic и содержащее только представления и статические ресурсы, такие как изображения и JavaScript
• YourApp.BusinessLogic.Tests: модульные тесты

Затем в свойствах конфигурации решения вы можете снять отметку с действия Build для проекта модульных тестов. Это уменьшит время между нажатием Ctrl + F5 и отображением приложения в веб-браузере.

Answer 3

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

Например, в качестве моей конфигурации у меня есть Debug, Staging, Production и Unit Test. Сборка Debug не собирает мой проект Web Deployment или мой модульный тестовый проект. Это сокращает время сборки.

Answer 4

Я не думаю, что "code-build-run" - это какой-то принцип TDD.

Вам не нужно нулевое время сборки - это необоснованное ожидание - 5-10 секунд - это здорово.

Вы не запускаете тесты после каждого крошечного инкрементального изменения. Напишите группу тестов вокруг интерфейса для нового класса (скажем, контроллера или библиотечного класса, который будет реализовывать бизнес-логику). Создайте скелет класса - наименьшую скомпилированную версию класса. Запустите тесты - все должно провалиться. Реализуйте базовую логику класса. Запустите тесты. Работайте над ошибочным кодом, пока все тесты не пройдут. Рефакторинг класса. Запустите тесты.

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