1. дома
  2. Вопрос и ответ
  3. Visual Studio перестраивает немодифицированные проекты

Visual Studio перестраивает немодифицированные проекты

2013-02-17 4 views
56

Итак, как гласит название, у меня есть VS2010-решение с ~ 50 проектами в нем прямо сейчас. Если я внес изменения в проект «верхнего уровня», который ничего не ссылается, VS все еще перестраивает все 50 проектов. Я запускаю Visual Studio 2010 Ultimate без каких-либо надстроек. Я использую ILMerge для консолидации всех проектов в один файл.Visual Studio перестраивает немодифицированные проекты

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

Я прочитал все отзывы и комментарии для:

Visual Studio 2008 keeps rebuilding

Visual studio keeps building everything

Strange VS2010 build glitch occurs in my solution

Reasons for C# projects to rebuild in Visual Studio

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

Я включил «Инструменты»> «Параметры»> «Проекты и решения»> «Сборка и запуск». Создавайте только проекты запуска и зависимости от запуска », но без эффекта.

Кроме того, если я просто перестрою проект «среднего уровня», который имеет только 8 (в) прямых зависимостей, то он все еще строит все 8 проектов, хотя ILMerge не вызывается и ни один из зависимых проектов не был изменен.

Благодарим всех вас за понимание, которое вы можете предоставить.

Добавлено

Чтобы проверить некоторые из предложений, которые я создал новый проект WinForms с нуля. Затем я создал два новых проекта внутри этого решения. Я скопировал весь код и ресурсы (не файл проекта) из моих двух проектов «самого низкого уровня» в два новых проекта (я сделал это, отбросив файлы и папки из Explorer в проект в Visual Studio).

Самый низкий проект, назовем его B, не ссылался ни на один другой проект. Следующий проект, A, ссылка B только. Поэтому, как только я добавлю необходимые ссылки на .NET и внешние сборки для проектов, тогда будет построено решение.

У меня тогда был мой новый проект проекта WinForm A и сделал полную сборку. Таким образом, ссылка цепи:

WinForm -> ->B

Я модифицируется WinFormтолько и сделал стандартную сборку (F6). Как и прежде, Visual Studio перестроила все три проекта.

После некоторого систематического eleminiation исходных файлов в проекте B Я обнаружил, что если я удалил мой Resources.Designer.cs и Resources.resx (и закомментирован код, который сделал использование .Properties.Resources объекта этих ресурсов), то модификацией WinForm больше не будет перестраивать все решение и будет восстанавливать только WinForm.

Добавление Resources.resx и Resources.Designer.cs обратно к проекту B (но оставляя ссылочный код комментировал так, что ничего не делает использование ресурсов) будет повторно ввести полное поведение сборки.

Чтобы узнать, были ли повреждены мои файлы ресурсов, я удалил их еще раз, а затем создал новый (через Project Properties -> Resources) и повторно добавил тот же ресурс, что и раньше, который был единственным файлом Excel. С помощью этой установки все еще будет происходить полная перестройка.

Затем я удалил единственный ресурс, но оставил файл ресурсов в проекте B. Даже если ресурсы не добавлены, но файл ресурсов все еще находится в проекте, произойдет полная (ненужная) перестройка.

Похоже, что наличие файла ресурсов, добавленного в проект (.NET 3.5), приведет к тому, что Visual Studio 2010 всегда будет перестраивать этот проект. Является ли это ошибкой или предполагаемым/ожидаемым поведением?

Спасибо всем!

источник

2013-02-17 Matt Klein

+0

может вы пытаетесь создать его с помощью msbuild напрямую и посмотреть, все ли происходит. –

+0

Я понимаю, что VS вызывает msbuild (и что проект в основном является сценарием msbuild http://stackoverflow.com/questions/1497344/integrating-msbuild-into-visual -студия), поэтому я не уверен, что это изменит любой г. Я подозреваю, что просто закончил бы воссоздать один и тот же скрипт сборки, а затем запустил его из командной строки. Есть ли способ, которым работает msbuild напрямую, будет другим? Или, возможно, каким-то образом узнать, почему msbuild считает, что проекты необходимо перестроить? –

+0

Вы строите или перестраиваете? –

ответ

15

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

я первоначально имел около 5 проектов из 50, которая содержала Resources раздел. Эти проекты всегда будут перестроены, и, следовательно, все, от чего они зависят, также будет перестроено. Один из этих 5 проектов был «базовой» библиотекой уровня, на которую ссылались 48 других проектов, поэтому 96% моего проекта будут перестраиваться каждый раз, даже если это ему не понадобится.

Моим обходным путем было использование инъекций зависимостей, интерфейсов и выделенного проекта «Ресурсы». Вместо того, чтобы эти 5 проектов ссылались на свой собственный объект Resources, я создал интерфейс в каждом проекте, который обеспечивал бы нужные ресурсы.Затем классы, которым нужны эти ресурсы, потребовали бы, чтобы интерфейс был передан во время их создания в конструкторе (впрыск конструктора).

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

Наконец, в моем проекте «Верхний уровень», в котором ничего не упоминалось (и где exe фактически был построен, и мой корень состава живет), я ссылался на проект «Ресурсы», подключил DI, и мы ушли.

Это означает, что каждый раз будут восстановлены только два проекта («Ресурсы» и «Верхний уровень»), и если я сделаю частичную сборку (Shift-F6), они не будут полностью восстановлены.

Опять же, не очень хорошая работа, но с 48 проектами, которые строятся каждый раз, когда сборка займет около 3 минут, поэтому я терял 30-90 минут в день с ненужными перестройками. Некоторое время потребовалось рефакторинг, но я думаю, что это была хорошая инвестиция.

Вот упрощенная схема. Обратите внимание, что зависимости от Main.exe до Proj1 и Proj2 не показаны для уменьшения помех.

Diagram of solution

С помощью этой конструкции, я могу сделать сборку Proj1 или Proj2, не вызывая полное восстановление, так как они не имеют никаких зависимостей от Resources в разделе. Только Main знает про Resources осуществления.

источник

2013-02-27 20:30:02

0

Вот ответ от VS2010 always rebuilds solution?

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

источник

2013-02-17 01:01:49

+0

Я не уверен, что означало «изменение файлов проекта», но я дал остальную часть снимка без эффекта. Похоже, что это может быть связано с файлом ресурсов (см. Добавленную информацию к вопросу). –

0

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

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

источник

2013-02-17 03:37:23

+0

После некоторых обширных исследований, похоже, что «Resource.resx» может быть причиной такого поведения. Я добавил информацию к моему вопросу, чтобы описать мои эксперименты. –

+0

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

+0

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

12

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

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

источник

2014-04-28 12:08:58

+0

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

+0

Что делать, если у меня 7 тысяч миллионов файлов? –

+0

Вы можете создать небольшой скрипт/программу, которая просматривает файл проекта или файл .filter и проверяет, существуют ли указанные файлы. –

0

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

источник

2015-01-26 13:58:10 PhonPanom

91

Открытые инструменты - Параметры, выберите «Проекты и решения» - выполните сборку и запуск в дереве, а затем установите «Объяснение вывода проекта проекта MSBuild» в «Диагностика». В результате будет выведена причина для строительства проекта, то есть

Проект «ReferencedProject» не обновляется. Элемент проекта c: \ some.xml имеет атрибут «Копировать в выходной каталог», установленный в «Копировать всегда».

Проект "MyProject" не обновляется. Входной файл 'c: \ ReferencedProject.dll' изменяется после выходного файла 'c: \ MyProject.pdb'.

В этом случае исправление должно скопировать some.xml только в том случае, если оно более новое.

События до и после сборки могут также инициировать сборку.

источник

2015-04-15 11:40:06 user3285954

+23

Я считаю, что это лучший ответ, так как он доводит вас до сути понимания того, что вызывает повторение строчек, а не просто гадания или эксперименты. –

+0

Приятно знать! Я блуждал, почему перестройка проекта также перестраивает все проекты, на которые делается ссылка. Диагностический журнал объясняет: «Целевая» CleanReferencedProjects: (TargetId: 8) »« :) – FrankyHollywood

+0

Очень полезный совет, спасибо! –

0

Для этой категории проблем с установкой задания вывода MSBuild на «диагностику» действительно является необходимым первым шагом.В большинстве случаев заявленная причина для повторных построений будет достаточной для того, чтобы действовать, НО иногда MSBuild ошибочно утверждает, что некоторые файлы изменены и их необходимо скопировать.

Если это так, вам нужно либо отключить туннелирование NTFS, либо дублировать вашу выходную папку на новое место. Here it is in more words.

источник

2015-08-16 17:58:00

4

В моем случае виновником была ссылка «Копировать местность» ссылочной dll, установленной в true, и «Копировать в каталог вывода», чтобы установить файл, установленный для Копировать всегда.

источник

2015-11-27 05:38:41

9

Я была такая же проблема в VS 2015.

Что сделал трюк для меня:

  1. Один проект ссылается на себя копировать в каком-то другом проекте бункером (волшебный, да). Этот тип материала можно найти при переключении на вывод диагностической сборки (в вариантах построения), а затем попытаться построить проекты один за другим из иерархии проектов - если вы видите проект, который перестраивается, даже если ничего не было изменено, Рекомендации.
  2. Я поменял все файлы «копировать всегда» во всех проектах, чтобы «копировать, если новый». В основном, во всех .csproj файлы заменить <CopyToOutputDirectory>Always</CopyToOutputDirectory> на <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  3. Тогда я отключил туннелирование NTFS, как описано в статье this с этим Powershell скрипт:

New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"

После того, что я нуждался в восстановлении и кажется, работает пока.

источник

2016-03-20 19:31:22

+0

большое спасибо. Шаг 3 был ненужным для меня – Persi

+0

Есть ли быстрый способ сделать это (например, какой-то конкретный текст, который я могу выполнить)? Я столкнулся с той же проблемой в VS 2015, и у меня есть довольно большой файл решения (в том числе некоторые проекты, которые мне не разрешают изменять, потому что они «не принадлежат» мне). – EJoshuaS

0

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

В этом случае вы можете рекурсивно потрогать все файлы с помощью Git Баш (да, в Windows):

find . -exec touch {} \;

источник

2017-02-10 05:00:40 Mikhail

 Смежные вопросы

  • Нет связанных вопросов^_^