Причины для проектов C # для перестройки в Visual Studio

Question

У меня есть большое решение, около 320 проектов, где даже небольшие изменения в одной веб-форме приводят к длительному времени сборки для тестирования / отладки небольших изменений.Я подозреваю, что задачи копирования файлов после сборки для «касания» даты и времени файла приводят к нескольким перестройкам.

Существуют ли другие причины, по которым VS 2010 запускает перестройку, отличную от исходных файлов, которые новее двоичных файлов вывода,Отсутствие каких-либо сильных влияний имен и версий?

ADDENDUM: Я не имею непосредственного влияния на размер или форму исходного дерева.Это основа стабильного основного продукта, и любые краткосрочные «некоммерческие» изменения считаются рискованными или дорогостоящими.Я затрону вопросы, упомянутые в ответах, которые я получу здесь, в качестве вклада в будущие направления проекта.

Answer 1

C # перестраивается, потому что файл был изменен, или зависимость была изменена, но также часто по «безо всякой очевидной причине».Вы можете часто собирать 2 или 3 раза подряд, не внося ни одного изменения, и C # откатит и перестроит огромное количество кода.

Включите Инструменты> Параметры> Проекты и решения> Проекты и решения> Построить и запустить> Толькостроить запускаемые проекты и зависимости от запуска.Это минимизирует сборку только до тех зависимостей проекта, которые вы намереваетесь выполнить, поэтому, если все не является одним огромным деревом зависимостей, это значительно сократит число проектов, рассматриваемых в сборке.

Однако лучшее решение, во-первых, не просить его скомпилировать.

• Каждый проект добавляет дополнительную сборку к сборке.На моем ПК это около 3 секунд.Объединяя код двух проектов в один файл .csproj, я экономлю 3 секунды времени сборки.Таким образом, для более 300 проектов вы можете сократить время сборки на 10 минут, просто объединив проекты - то есть, где это возможно, используйте много модулей / пространств имен в одной сборке, а не во многих сборках.Вы также обнаружите, что время запуска вашего приложения также улучшилось.

• Многие проекты не требуют постоянной сборки.Разбейте их как библиотечные проекты и просто создайте ссылку на (ссылку) на двоичные файлы

• Также отключите «копировать локальные» и вместо этого направьте все выходные пути в общую папку - это значительно сократит накладные расходы наизбегая создания 320 копий 320 dll по всему жесткому диску.

• Добавляйте новые конфигурации сборки (например, «Debug FastBuild»), которые собирают только те сборки, над которыми вы фактически работаете.С помощью менеджера конфигурации вы можете отменить пометку проектов, которые вы не хотите создавать, и, прежде всего, они игнорируются системой сборки.После того, как вы получите код из системы контроля версий, соберите полную сборку «Debug», чтобы обновить все, а затем переключитесь обратно на «fastbuild»

Answer 2

Вы можете попытаться построить свое решение, используя msbuild и / v: d (для ведения журнала диагностики).

В журнале могут содержаться подсказки, почему проект не актуален.

Answer 3

Я думаю, что в 320 проектах вы давно превысили лимит того, что Visual Studio было разработано для комфортного выполнения.

Здесь есть много полезных советов, но если вам действительно нужно сохранить 320 проектов, вы можете отказаться от Visual Studio для сборки и разработки собственного процесса сборки.

Как я уже говорил в своем комментарии, по крайней мере для Windows, моя рекомендация для инструмента для сборки - psake , который построен на PowerShell (и, следовательно, включен в каждую современную Windows-машину), довольно мощный и легкий достаточно, чтобы передать все это вашему исходному контролю.

Answer 4

Сначала убедитесь, что ссылки на другие проекты являются ссылками ПРОЕКТА, а не ссылками на сборки.

Во-вторых, проверьте круговые ссылки.

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

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

Answer 5

320 Проекты - это множество файлов в дереве зависимостей: все они должны проверяться на наличие изменений механизмом сборки. Использование что-то вроде Process Monitor позволит вам увидеть, какие операции с файлами выполняются для подтверждения этого.

Также 320 сборок (поверх сборок .NET Framework), загружаемых во время выполнения, замедляют работу вашего приложения и действительно замедляют отладчик (много символов для загрузки). Посмотрите на отладку | Windows | Модули, чтобы увидеть загруженные модули).

Наряду с сокращением количества проектов в решении (вполне возможно иметь несколько решений с подмножеством проектов), вам действительно нужно столько отдельных проектов? Вне отладчика загрузчик .NET загружает и JIT-код только из сборок по мере необходимости, более крупные сборки не означают более медленного времени загрузки и позволяют избежать накладных расходов на сборку из загрузчика Windows.