У нас есть почти 100 проектов в одном решении и время сборки dev всего за несколько секунд:)

для локальных сборок разработки мы создали добавление Visual Studio, которое изменяет Project references до DLL references и выгружает ненужные проекты (и возможность переключить их обратно, конечно).

• построить все наше решение после
• выгрузите проекты, над которыми мы в настоящее время не работаем, и измените все ссылки проекта на DLL ссылки на литературу.
• перед регистрацией измените все ссылки из DLL на ссылки проекта.

наши сборки теперь занимают всего несколько секунд, когда мы работаем только над несколькими проектами одновременно. Мы также можем отлаживать дополнительные проекты, поскольку они связаны с библиотеками отладки. Инструмент обычно занимает 10-30 секунд, чтобы сделать большое количество изменений, но вам не нужно делать это так часто.

Обновление Май 2015 Года

сделка, которую я сделал (в комментариях ниже), было то, что я бы выпустил плагин для Open Source если он получает достаточный интерес. 4 года спустя он имеет только 44 голоса (и Visual Studio теперь имеет две последующие версии), поэтому в настоящее время это проект с низким приоритетом.

У меня была аналогичная проблема с решением 21 проекта и 1/2 миллиона LOC. Самым большим отличием было получение более быстрых жестких дисков. Из монитора производительности " Avg. Очередь дисков " значительно подпрыгнет на ноутбуке, указывая, что жесткий диск был горлышком бутылки.

вот некоторые данные для общего времени восстановления...

1) ноутбук, Core 2 Duo 2GHz, привод 5400 об / мин (не уверен в кэше. Был стандартным Dell inspiron).

Время Восстановления = 112 считанные секунды.

2) Рабочий стол (стандартный выпуск), Core 2 Duo 2.3 Ghz, одиночный 7200rpm Drive 8MB Cache.

время восстановления = 72 секунды.

3) Рабочий стол Core 2 Duo 3Ghz, один 10000 об / мин WD Raptor

время восстановления = 39 секунд.

привод 10,000 RPM не может быть занижен. Сборки, где значительно быстрее плюс все остальное, как отображение документации, с помощью проводника файлов было заметно быстрее. Это было большое повышение производительности ускорение цикла код-сборка-запуск.

Учитывая, какие компании тратят на зарплаты разработчиков, это безумие сколько они могут тратить купить, оснащая их теми же ПК,что и администратор.

для сборок C# .NET вы можете использовать .NET Демон. Это продукт, который берет на себя процесс сборки Visual Studio, чтобы сделать его быстрее.

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

выключите антивирус. Он добавляет возраст ко времени компиляции.

использовать распределенную компиляцию. Xoreax IncrediBuild может сократить время компиляции до нескольких минут.

Я использовал его на огромном решении C\C++, которое обычно занимает 5-6 часов для компиляции. IncrediBuild помог сократить это время до 15 минут.

инструкции по сокращению времени компиляции Visual Studio до нескольких секунд

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

стратегия преодоления этого заключается в отключении автоматического построение дерева ссылок. Для этого используйте "Configuration Manager"(сборка / Configuration Manager...затем в раскрывающемся списке конфигурация активного решения выберите "Создать"), чтобы создать новую конфигурацию сборки под названием "ManualCompile", которая копирует конфигурацию отладки, но не устанавливает флажок "создать новые конфигурации проекта". В этой новой конфигурации сборки снимите флажки с каждого проекта, чтобы ни один из них не создавался автоматически. Сохраните эту конфигурацию, нажав "закрыть". Эта новая сборка конфигурация добавляется в файл решения.

вы можете переключаться с одной конфигурации сборки на другую через раскрывающийся список конфигурации сборки в верхней части экрана IDE (тот, который обычно показывает либо "Debug", либо "Release"). Фактически эта новая конфигурация сборки ManualCompile сделает бесполезными параметры меню сборки для: "Build Solution" или "Rebuild Solution". Таким образом, в режиме ManualCompile необходимо вручную создавать каждый изменяемый проект, что можно сделать, щелкнув правой кнопкой мыши по каждому затронутому проекту в обозревателе решений, а затем выбрав "построить" или "перестроить". Вы должны видеть, что общее время компиляции теперь будет составлять всего несколько секунд.

чтобы эта стратегия работала, необходимо, чтобы номер версии, найденный в файлах AssemblyInfo и GlobalAssemblyInfo, оставался статическим на машине разработчика (не во время сборки выпуска, конечно), и чтобы вы не подписывали свои библиотеки DLL.

потенциальный риск используя эту стратегию ManualCompile, разработчик может забыть скомпилировать необходимые проекты, и когда они запускают отладчик, они получают неожиданные результаты (невозможно прикрепить отладчик, файлы не найдены и т. д.). Чтобы избежать этого, вероятно, лучше всего использовать конфигурацию сборки "Debug" для компиляции больших усилий кодирования и использовать только конфигурацию сборки ManualCompile во время модульного тестирования или для внесения быстрых изменений с ограниченной областью действия.

Если это C или C++, и вы не используете предварительно скомпилированные заголовки, вы должны быть.

У нас было 80+ проектов в нашем основном решении, которое заняло от 4 до 6 минут, чтобы построить в зависимости от того, какую машину разработчик работал. Мы считали, что это слишком долго: для каждого теста он действительно съедает ваши FTEs.

Итак, как получить более быстрое время сборки? Как вы, кажется, уже знаете, это количество проектов, которые действительно повредили buildtime. Конечно, мы не хотели избавляться от всех наших проектов и просто бросать все исходные файлы в один. Но у нас были некоторые проекты мы все же смогли объединить: поскольку каждый "проект репозитория" в решении имел свой собственный unittest-проект, мы просто объединили все unittest-проекты в один глобальный unittest-проект. Это сократило количество проектов примерно с 12 проектами и каким-то образом сэкономило 40% времени на создание всего решения.

мы думаем о другом решении, хотя.

вы также пытались настроить новое (второе) решение с новым проектом? Эта секунда решение должно просто включать все файлы, используя папки решений. Потому что вы можете быть удивлены, увидев время сборки этого нового решения с одним проектом.

однако работа с двумя различными решениями потребует некоторого тщательного рассмотрения. Разработчики могут быть склонны фактически-работать - во втором решении и полностью пренебрегать первым. Поскольку первое решение с проектами 70+ будет решением, которое позаботится о вашей объектной иерархии, это должно быть решение, в котором ваш buildserver должен запускать все ваши unittests. Таким образом, сервер для непрерывной интеграции должен быть первым проектом / решением. Вы должны поддерживать свою объектную иерархию, правильно.

второе решение только с одним проектом (который будет строить mucho быстрее) будет, чем проект, где тестирование и отладка будут выполняться всеми разработчиками. Вы должны заботиться о них, глядя на buildserver, хотя! Если что-то сломается, это нужно исправить.

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

кроме того, они установлены не копировать локально, за исключением случаев, когда это абсолютно необходимо (проект master EXE).

Я разместил этот ответ первоначально здесь: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 Вы можете найти много других полезных советов на этой странице.

при использовании Visual Studio 2008 можно скомпилировать с помощью флага / MP для параллельного построения одного проекта. Я читал, что это также недокументированная функция в Visual Studio 2005, но никогда не пробовал себя.

вы можете создавать несколько проектов параллельно, используя флаг /M, но обычно это уже установлено на количество доступных ядер на машине, хотя это относится только к VC++, я считаю.

Я заметил, что этот вопрос стар, но тема по-прежнему представляет интерес сегодня. Та же проблема укусила меня в последнее время, и две вещи, которые улучшили производительность сборки, были (1) использовать выделенный (и быстрый) диск для компиляции и (2) использовать ту же папку вывода для всех проектов и установить CopyLocal в False для ссылок на проекты.

дополнительные ресурсы:

• https://stackoverflow.com/questions/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

некоторые инструменты анализа:

инструменты- > параметры - >настройки проекта VC++ - > время сборки = да скажет вам время сборки для каждого vcproj.

добавить /Bt переключитесь в командную строку компилятора, чтобы увидеть, сколько каждый файл CPP взял

использовать /showIncludes чтобы поймать вложенные includes (файлы заголовков, которые включают другие файлы заголовков), и посмотреть, какие файлы могут сохранить много ввода-вывода с помощью прямых объявлений.

Это поможет вам оптимизировать производительность компилятора устранение зависимостей и производительности свиней.

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

в моем случае проект, который занял 5 минут, чтобы построить на 6-ядерном i7 на 7200 RPM SATA-диске С Incredibuild, был уменьшен всего на 15 секунд с помощью RAM-диска. Учитывая необходимость чтобы перекопировать в постоянное хранилище и потенциал для потерянной работы, 15 секунд недостаточно стимула использовать RAM-диск и, вероятно, не так много стимула тратить несколько сотен долларов на диск с высокой частотой вращения или SSD.

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

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

насколько велик ваш каталог сборки после выполнения полной сборки? Если вы придерживаетесь настройки по умолчанию, то каждая сборка, которую вы создаете, будет копировать все DLL своих зависимостей и зависимостей зависимостей и т. д. в его каталог bin. В моей предыдущей работе при работе с решением ~40 проектов мои коллеги обнаружили, что на сегодняшний день самой дорогой частью процесса сборки является копирование этих сборок снова и снова, и что одна сборка может генерировать гигабайты копий одни и те же библиотеки DLL снова и снова.

вот несколько полезных советов от Патрика Смаккьи, автора NDepend, о том, что, по его мнению, должно и не должно быть отдельными сборками:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

есть в основном два способа обойти это, и оба имеют недостатки. Один из них заключается в сокращении количества сборок, что, очевидно, является большой работой. Другой-реструктурировать каталоги сборки, чтобы все ваши папки bin были объединены, а проекты не копировали библиотеки DLL своих зависимостей - им это не нужно, потому что все они уже находятся в одном каталоге. Это значительно уменьшает количество файлов, созданных и скопированных во время сборки, но это может быть трудно настроить и может оставить вас с некоторым трудом вытаскивая только библиотеки DLL, необходимые для конкретного исполняемого файла для упаковки.

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

Если вы беспокоитесь о разных версиях DLL, перепутанных, используйте статические библиотеки.

выключите интеграцию VSS. Возможно, у вас нет выбора в его использовании, но DLL все время "случайно" переименовываются...

и определенно проверьте настройки предварительно скомпилированного заголовка. Путеводитель Брюса Доусона немного староват, но все же очень хорошо-проверьте это:http://www.cygnus-software.com/papers/precompiledheaders.html

У меня есть проект, который имеет 120 или более exes, libs и dll и занимает значительное время для сборки. Я использую дерево пакетных файлов, которые вызывают файлы make из одного главного пакетного файла. В прошлом у меня были проблемы с нечетными вещами из инкрементных (или темпераментных) заголовков, поэтому я избегаю их сейчас. Я делаю полную сборку нечасто и обычно оставляю ее до конца дня, пока я иду на прогулку в течение часа (поэтому я могу только догадываться, что это занимает около получаса). Поэтому я понимаю, почему это так не работает для работы и тестирования.

для работы и тестирования у меня есть другой набор пакетных файлов для каждого приложения (или модуля или библиотеки), которые также имеют все настройки отладки на месте, но они по-прежнему вызывают те же файлы make. Время от времени я могу переключать DEBUG on of off, а также принимать решения о сборке или создании, или если я хочу также создавать библиотеки, от которых может зависеть модуль, и т. д.

пакетный файл также копирует завершенный результат в тест (или несколько) папки. В зависимости от настроек это завершается за несколько секунд до минуты (в отличие от, скажем, получаса).

Я использовал другую IDE (Zeus), поскольку мне нравится контролировать такие вещи .rc-файлы и на самом деле предпочитают компилироваться из командной строки, хотя я использую MS compliers.

счастлив опубликовать пример этого пакетного файла, если кто-то заинтересован.

отключить индексацию файловой системы в исходных каталогах (в частности, в каталогах obj, если вы хотите, чтобы ваш источник был доступен для поиска)

если это веб-приложение, установка пакетной сборки в true может помочь в зависимости от сценария.

<compilation defaultLanguage="c#" debug="true" batch="true" >  

вы можете найти обзор здесь: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

вы также можете проверить циклические ссылки на проекты. Когда-то это было проблемой для меня.

Что есть:

Project A references Project B

Проект C ссылается на проект a

одной из более дешевых альтернатив Xoreax IB является использование того, что я называю сборками uber-файлов. Это в основном .cpp файл, который имеет

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

затем вы компилируете блоки uber вместо отдельных модулей. Мы видели время компиляции от 10-15 минут до 1-2 минут. Возможно, вам придется experiemnt с Сколько #включает в файл Убер смысла. Зависит от проектов. так далее. Может быть, вы включаете 10 файлов, может быть, 20.

вы платите стоимость так остерегайтесь:

1. вы не можете щелкнуть правой кнопкой мыши файл и сказать "compile..."поскольку вы должны исключить отдельные файлы cpp из сборки и включить только файлы Uber cpp
2. вы должны быть осторожны со статическими глобальными конфликтами переменных.
3. когда вы добавляете новые модули, вы должны держать файлы uber в актуальном состоянии

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

Если это проект C++, то вы должны использовать предварительно скомпилированные заголовки. Это делает огромную разницу во времени компиляции. Не уверен, что сл.exe действительно делает (не используя предварительно скомпилированные заголовки), похоже, ищет lots заголовков STL во всех неправильных местах, прежде чем, наконец, перейти к правильному местоположению. Это добавляет целые секунды к каждому .файл cpp составляется. Не уверен, что это сл.ошибка exe или какая-то проблема STL в VS2008.

глядя на машину, на которой вы строите, она оптимально настроена?

мы только что получили время сборки для нашего крупнейшего продукта корпоративного масштаба C++ от в 19 часов до 16 минут путем обеспечения правильного драйвера фильтра SATA был установлен.

тонкий.

в Visual Studio 2005 есть недокументированный переключатель /MP, см. http://lahsiv.net/blog/?p=40, что позволит параллельную компиляцию на основе файла, а не на основе проекта. Это может ускорить компиляцию последнего проекта или, если вы компилируете один проект.

при выборе CPU: размер кэша L1, похоже, оказывает огромное влияние на время компиляции. Кроме того, обычно лучше иметь 2 быстрых ядра, чем 4 медленных. Visual Studio не использует дополнительные ядра очень эффективно. (Я основываю это на своем опыте работы с компилятором C++, но это, вероятно, также верно для C# one.)

Я также теперь убежден, что есть проблема с VS2008. Я запускаю его на двухъядерном ноутбуке Intel с 3G Ram, с выключенным антивирусом. Компиляция решения часто довольно скользкая, но если я отлаживал последующую перекомпиляцию, она часто замедляется до обхода. Из непрерывного света основного диска ясно, что есть узкое место для ввода-вывода диска (вы также можете его услышать). Если я отменю сборку и завершение работы, активность диска остановится. Перезапустите VS, перезагрузите решение, а затем перестроить, и это намного быстрее. Unitl в следующий раз

мои мысли в том, что это проблема подкачки памяти - VS просто заканчивается память, и O/S начинает подкачку страниц, чтобы попытаться освободить место, но VS требует больше, чем может доставить подкачка страниц, поэтому он замедляется до обхода. Я не могу придумать другого объяснения.

против наверняка не рад, да?

Он уверен, что есть проблема с VS2008. Потому что единственное, что я сделал, это установить VS2008 для обновления моего проекта, который был создан с помощью VS2005. У меня есть только 2 проекта в моем решении. Он не большой. Сборник с VS2005: 30 secondes Компиляция с VS2008: 5 минут

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

• новый ноутбук 3GHz-сила потерянного использования творит чудеса, когда whinging к управлению
• отключить антивирус во время компиляции
• "отключение" от VSS (фактически сети) во время компиляции-я могу заставить нас полностью удалить интеграцию VS-VSS и придерживаться к использованию пользовательского интерфейса VSS

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

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

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

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

есть несколько вещей, которые я нашел полезными для ускорения C# / .NET сборки:

• объедините небольшие проекты в более крупные проекты, поскольку есть большие накладные расходы на проект при создании решения. (Используйте вопросом, что происходит при необходимости для управления вызовом через слои)

• сделайте все наши проекты встроенными в некоторый выходной каталог, а затем установите" копировать локальный " в false для всех ссылок на проект – это может привести к большой скорости вверх должной к уменьшенному IO.

• поворот вашей проверки вирусов, чтобы увидеть, если это имеет большое значение; если так найти быстрее вирус checker, или исключить" горячие " папки из проверки вирусов сканирования

• используйте perforce monitor и внутренний инструмент sys, чтобы увидеть, как ваши компиляции занимают так много времени.

• рассмотрим ram-диск, чтобы поместить ваш выходной каталог на.

• рассмотрите возможность использования SSD

• больше памяти может иметь большой эффект в разы – (уменьшите ОЗУ в машине, если вы получите большое замедление, удалив немного ОЗУ, вы можете получить большую скорость, добавив больше) Удалите ненужные ссылки на проект (возможно, сначала вам придется удалить ненужные "использования")

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