Visual Studio не перестраивает сборку без необходимости.Он «должен», когда любое из следующих изменений:
- Свойства сборки, такие как Target CPU / Framework
- Зависимости в ссылочных сборках (если объект A1 в сборке A требует B1 в Bи B1 изменяется, сборки A и B должны быть перестроены)
- Исходный код, который будет компилироваться в сборку (очевидно)
Кроме того, скорость сборки меньше зависит от чистого количества кодаили даже количество классов, но количество строящихся проектов.При постоянном количестве строк кода, которые должны быть полностью перестроены, решение, которое собирается в одну сборку, будет построено быстрее, чем решение, встраиваемое в 10 сборок, поскольку при сборке, повторяющейся для каждой сборки, накладываются большие накладные расходы.сборка.
Вот несколько основных советов по увеличению скорости сборки:
- Постарайтесь сохранить изменения на как можно более высоком уровне в справочной иерархии сборки.Когда A зависит от B, а B зависит от C, если изменяется A, необходимо перестраивать только A, но если B или C изменяются, все, что выше, также должно быть перестроено.Это не всегда возможно, но уменьшение количества сборок приведет к уменьшению этой иерархии, поэтому даже если вам нужно перестроить более низкую сборку, меньше других сборок зависит от нее.
- Слабое сопряжение кода с использованием интерфейсовдля любой зависимости между сборками и разделения интерфейсов в их собственную сборку.Класс A, зависящий от класса B, должен быть восстановлен, если B изменится.Однако, если A вместо этого зависит от интерфейса I, который реализует B, A не придется перестраивать при изменении B;только если я это сделаю (что гораздо реже).Тем не менее, VS строит сборки;если I находится в сборке с B, сборку, содержащую A, необходимо будет перестроить, если B изменится, даже если я этого не сделал.
- Создание конфигураций сборки, которые собирают только то, что абсолютно необходимо для этой конфигурации.Сборка Debug не должна перестраивать установщик.Кроме того, сборка выпуска не должна перестраивать сборки тестирования.Однако по умолчанию новые проекты включаются в каждую конфигурацию сборки, поэтому вам необходимо регулярно поддерживать эти конфигурации.
- На фронте установщика посмотрите, можете ли вы разделить это построение на отдельную конфигурацию.,Инсталляторы - самая медленная одиночная сборка любого перестроения решения;сначала они дважды проверяют, что все сборки собраны, затем они собирают все, что им нужно для включения, и архивируют его в CAB-файл, который затем инкапсулируется с логикой установки в MSI.Старайтесь не создавать его, если только вы на самом деле не производите кандидата на выпуск.
- Делайте «Rebuild Solution» только тогда, когда это необходимо.Rebuild Solution выполняет «Очистку» плюс «Сборку», что приводит к необходимости ВСЕГО создавать заново.
- Минимизация действий после сборки.Аналогично созданию конфигов, которые вырезают ненужные сборки, создание конфигов, позволяющих пропустить действия после сборки, когда в них нет необходимости, или просто перестановке решения, чтобы сборка оказалась в нужном месте для начала, значительно ускорит вас.
- Такие инструменты, как клиенты ReSharper или SVN, а также помощники по индексированию сходят с ума, когда вы перестраиваете, повторно анализируете новые сборки, определяете изменения и т. Д. Убедитесь, что служба индексирования Windows не индексирует каталоги исходного кода или какие-либо места вывода сборки,отключите ReSharper Solution Analysis и не включайте выходные данные сборки в версии SVN.