Visual Studio Long wait before Запуск сборки

У нас есть умеренно размерное решение, около 20 проектов. В одном из них у меня есть мои бизнес-подразделения. При компиляции любого проекта визуальная студия ждет и занимает около полутора минут в этом проекте BusinessEntities.

Я пробовал наше решение в SharpDevelop, и оно составляет наше полное решение за 18 секунд. Аналогичное время с MSBuild.

Я предполагаю, что VS пытается выяснить, нуждается ли проект в компиляции, но этот процесс примерно в 15 раз медленнее, чем фактически выполняет компиляцию!!

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

Могу ли я запретить VS проверять этот проект? И не компилировать проекты без такой проверки, как sharpdevelop?

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

Изменить: интересные результаты расследования: Задержка происходит только с одним из проектов. В диспетчере конфигурации я отключил все проекты, а затем скомпилировал каждый из них по отдельности. Все проекты собираются через несколько секунд! Дело в том, что если этот специальный проект создается напрямую, он компилируется через несколько секунд, если он создается (или пропускается, потому что он обновляется) в результате создания другого проекта, который зависит от него, VS висит около минуты и половины, а затем решает скомпилировать его (или пропустить). Мой вывод: Visual studio проверяет, не изменены ли какие-либо файлы, но по некоторым причинам для этого специального проекта он крайне неэффективен.

Ответ 1

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

Когда сборка будет построена, VS проверит ссылки целевой сборки, которые, если они построены с ошибкой или новые версии, могут включать в себя фактическую загрузку их в домене .Net, который несет все бремя загрузки сборки как хотя вы собираетесь его запустить. Сборка может постепенно замедляться, поскольку она восстанавливает все больше и больше проектов. Когда одна сборка становится новее, другие делают намного больше работы. Это одно из возможных объяснений того, почему построение само по себе, по сравнению с уже построенным, по сравнению с чистым зданием, все, по-видимому, имеют разные результаты. Это действительно то, что другие изменили, а не то, что было скомпилировано.

VS будет "пометить" последний "внутренний" номер сборки ссылочной сборки и посмотреть, действительно ли ссылочная сборка изменилась по мере ее прокрутки в процессе сборки. Если он не отличается, тонна работы пропускается. И да, есть внутренние номера сборки, которые вы не контролируете. Это никак не связано с фактическим компилятором С# или его работой или чем-либо после компиляции, но предварительно скомпилирует шаги, необходимые для наиболее общих случаев.

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

Перейдите к ссылкам одного из проектов в обозревателе решений:

1) нажмите ссылку

2) откройте панель свойств, если ее нет (не Страницы свойств или Property Manager)

3) посмотрите "Копировать локальную", "Вставить типы взаимодействия", "Сборка выходных данных"; они могут быть очень применимы и, вероятно, что-то хорошее знать независимо от того. Я настоятельно рекомендую посмотреть, что они делают в MSDN. "Сборка ссылочного вывода" может отображаться или не отображаться в списке.

4) выгрузите проект и отредактируйте файл .proj в VS как текст. найдите ссылку на сборку в XML и найдите 'Private'. Это означает, следует ли ссылаться на сборку, как будто она будет частной сборкой с точки зрения ссылочных сборок, а не общей. Это своего рода многословный способ сказать, будет ли эта сборка развернута как единое целое вместе с другими сборками. Это очень важно для освобождения вещей. Предпосылки: http://msdn.microsoft.com/en-us/magazine/cc164080.aspx

Итак, основная идея здесь заключается в том, что вы хотите настроить все из них как наименее дорогостоящие, как во время сборки, так и после развертывания. Если вы строите их вместе, то, например, вам, вероятно, действительно не нужно "Копировать местное". Я не хочу больше говорить о том, как вы должны их настраивать, не зная больше о ваших потребностях, но это очень хорошая вещь, чтобы прочитать несколько хороших параграфов о каждом. Это становится очень сложным, потому что вы также влияете на то, будет ли VS использовать устаревшую старую при разрешении до того, как восстановленная ссылка будет восстановлена. В качестве дополнительного примера, объясняющего, что это хорошо, чтобы прочитать об этом, Copy Local может использовать локальную копию, хотя ее устаревшая, поэтому наличие этого набора может быть двойным. Просто помните, что цель на данный момент заключается в том, чтобы снизить нагрузку VS, загружая новые сборные jsut, чтобы скомпилировать остальные.

Наконец, на данный момент я легко могу сказать, что повешение всего за 1,5 минуты очень удачное. Есть люди с гораздо худшими временами сборки из-за таких вещей:)

Ответ 2

Я бы подошел к Tools -> Options -> Projects and Solutions -> Build and Run, а затем изменил "сборку проекта MSBuild [output | build log] verbosity" на "Diagnostic". На этом уровне будут включены тайминги, которые помогут вам выявить проблему.

Ответ 3

У нас была та же проблема с веб-проектом ASP.NET MVC, работающим в Visual Studio 2013. Мы строим проект, и ничего не происходит примерно минуту или около того, а затем окно вывода показывает, что мы компилируем.

Вот что фиксировало это... откройте файл .csproj в текстовом редакторе и установите MvcBuildViews в false:

<MvcBuildViews>false</MvcBuildViews>

Мне пришлось использовать монитор процесса sysinternals, чтобы понять это, но это явно причина для моей ситуации. Сайт компилируется менее чем за 5 секунд и раньше занимал более минуты. В течение этой минуты процесс компиляции Asp.net помещал файлы и каталоги в папку Temporary Asp.net.

Предупреждение. Если вы установите это, вы больше не будете прекомпилировать свои представления, чтобы потерять способность видеть синтаксические ошибки в ваших представлениях во время сборки.

Ответ 4

Звучит глупо, но сначала удалите все точки останова. Это ускорило мои проверки перед сборкой в массовом порядке - до сих пор не знаю, почему.

Ответ 5

Некоторая идея устранения неполадок, о которой не упоминалось:

Чистый раствор?
Удалить папки Obj и Bin? FYI, ни Clean, ни Rebuild не будут удалять файлы без сборки, например файлы, скопированные во время команды предварительной сборки.
Отключите VS-сканирование внешних файлов. Параметры > инструменты > средa > документ > обнаружение при изменении файла вне среды
Откажитесь от истории SVN, чтобы подтвердить, когда она начнется? Что изменилось? Если файл проекта в первый день занимает одно и то же время, заново создайте проект, добавьте все файлы и создайте.

В противном случае вы могли бы запустить Process Monitor и сообщить нам, что Visual Studio делает на этапе предварительной сборки?

Ответ 6

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

Ответ 7

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

Ответ 8

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

Попробуйте визуализировать иерархию зависимостей проекта и установить зависимые проекты. Например, если ваш проект бизнес-объектов упоминается в каждом проекте, то при настройке каждого проекта этот проект должен быть выбран как зависимый.

Когда явный порядок построения не установлен, visual studio анализирует проекты для создания порядка построения проекта. Установка явных зависимых проектов wiki делает визуальную студию пропустить этот шаг и использовать предоставленный вами порядок.

Ответ 9

С такой чрезмерной задержкой в одном проекте и без какой-либо другой возможности, которая, по-видимому, послужит причиной, я попытался бы построить этот конкретный проект во время работы procmon от sysinternals и отфильтровать все сообщения об успешности. Вероятно, вы также можете сузить его до действий файловой системы. Из вашего описания я могу догадаться, что файлы блокируются внешним источником, например службами сбора событий или процессами управления потоками.

Другие вещи, которые следует учитывать, будут ли это полностью чистой машиной сборки или если она была использована, чтобы, возможно, протестировать сборки? Если да, есть ли вероятность, что кто-то сопоставил путь приложения IIS к проекту напрямую или зарегистрировал его как место службы?

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