Наш продукт имеет более 100 проектов (500 + ksloc производственного кода). Большинство из них - проекты С#, но мы также мало используем С++/CLI для связывания коммуникаций с собственным кодом.
Восстановление всего решения занимает несколько минут. Это здорово. Если я хочу перестроить решение, я ожидаю, что это займет некоторое время. То, что не хорошо, - это время, необходимое для создания решения после полной перестройки. Представьте, что я использовал полную перестройку и теперь без каких-либо изменений в решении я нажимаю Build (F6 или Ctrl + Shift + B). Почему требуется 35 секунд, если не было никаких изменений? На выходе я вижу, что он начал "строить" каждый проект - он не выполняет реальную сборку, но делает то, что потребляет значительное количество времени.
Эта задержка - это боль в заднице. Да, я могу улучшить время, не используя решение сборки, а только создав проект (Shift + F6). Если я запускаю проект сборки по конкретному тестовому проекту, над которым я сейчас работаю, он будет принимать "только" 8 + s. Он требует, чтобы я запускал сборку проекта по правильному проекту (тестовый проект также обеспечивал сборку зависимого проверенного кода). По крайней мере, тестировщик ReSharper правильно распознает, что только этот единственный проект должен быть сборкой, а повторный запуск обычно содержит только компиляцию 8 + s. Моя текущая кодировка Kata: не касайтесь Ctrl + Shift + B.
Сбор тестового проекта займет 8 секунд, даже если я не сделаю никаких изменений. Причина, по которой он занимает 8 секунд, состоит в том, что он также "строит" зависимости = в моем случае он "строит" более 20 проектов, но я вносил изменения только в unit test или одну зависимость! Я не хочу, чтобы он касался других проектов.
Есть ли способ просто сказать VS построить только проекты, в которых были сделаны некоторые изменения, и проекты, зависящие от измененных (предпочтительно эта часть как другая опция сборки)? Я беспокоюсь, вы скажете мне, что это именно то, что делает VS, но по-разному...
Я хочу улучшить свой опыт TDD и сократить время компиляции (в TDD компиляция может произойти дважды в минуту).
Чтобы сделать это еще более расстроенным, я работаю в команде, где большинство разработчиков работало над Java-проектами до присоединения к ней. Таким образом, вы можете себе представить, как они разозлились, когда они должны использовать VS, в отличие от полной инкрементной компиляции в Java. Мне не требуется инкрементальная компиляция классов. Я ожидаю, что мы будем работать с инкрементальной компиляцией решений. Особенно в продукте, таком как VS 2010 Ultimate, который стоит несколько тысяч долларов.
Я действительно не хочу получать ответы вроде:
- Сделайте отдельное решение
- Выгрузить проекты, которые вам не нужны.
- и др.
Я могу прочитать эти ответы здесь. Это не приемлемые решения. Мы не платим за VS, чтобы делать такие компромиссы.
