Visual Studio 2008 Создание ненужного проекта - PullRequest
29 голосов
/ 20 февраля 2009

У меня есть проект на C #, который включает в себя один exe и 11 библиотечных файлов. Exe ссылается на все библиотеки, а lib1 может ссылаться на lib2, lib3, lib4 и т. Д.

Если я внесу изменение в класс в lib1 и построю решение, я предположил, что нужно будет изменить только lib1 и exe. Однако все dll и exe создаются, если я хочу запустить решение.

Есть ли способ остановить построение зависимостей, если они не были изменены?

Ответы [ 13 ]

48 голосов
/ 22 апреля 2009

Ключ этой фразы? «Однако все dll и exe создаются , если я хочу запустить решение »

Visual Studio всегда будет пытаться собрать все при запуске одного проекта, даже если этот проект не зависит от всего. Однако этот выбор можно изменить. Перейдите в Инструменты | Параметры | Проекты и решения | Постройте и запустите и установите флажок «Создавать только запускаемые проекты и зависимости при запуске». Затем, когда вы нажмете F5, VS соберет только ваш стартовый проект и библиотеки DLL, от которых он зависит.

4 голосов
/ 16 апреля 2010

Я просто "исправил" ту же проблему с моим проектом VS. Visual Studio всегда перестраивала, даже если ничего не меняла. Мое решение: у одного cs-File была будущая временная метка (2015 год, это была моя ошибка). Я открыл файл, сохранил его, и моя проблема была решена !!!

4 голосов
/ 22 апреля 2009

У нас была похожая проблема на работе. В событиях после сборки мы вручную встраивали манифесты в выходные данные в каталоге bin. Visual Studio копировала ссылки на проекты из каталога obj (который не был изменен). Разница во времени привела к ненужным перестройкам.

Если ваши события после сборки изменяют выходные данные проекта, либо измените выходные данные в bin и obj dir ИЛИ скопируйте измененные выходные данные в bin bin поверх тех, что в obj dir.

4 голосов
/ 22 апреля 2009

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

Если вы используете «Любой процессор», то по какой-то причине он перестраивает все проекты независимо от изменений. Попробуйте использовать сборки, специфичные для процессора, то есть x86 или x64 (используйте платформу, которая зависит от архитектуры вашего компьютера). Работал для нас на сборках x86.

alt text
(источник: episerver.com )

4 голосов
/ 20 февраля 2009

Я не уверен, есть ли способ избежать построения зависимостей. Здесь вы можете найти некоторую информацию, например, установить copylocal в false и поместить dll в общий каталог.

Оптимизация сборки решения Visual Studio - куда помещать файлы DLL?

4 голосов
/ 20 февраля 2009

Вы можете снять флажок опции сборки для указанных проектов в вашей конфигурации решения :

SolutionProperties
(источник: microsoft.com )

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

build config
(источник: microsoft.com )

2 голосов
/ 22 апреля 2009

Теперь, после того, как я это скажу, придет какая-то пропеллерная головка и вступит в противоречие со мной, но из Visual Studio нет способа сделать то, что вы хотите. Есть способ сделать это вне VS, но сначала у меня есть вопрос:

С какой стати вы хотите это сделать? Может быть, вы пытаетесь сохранить циклы процессора или сэкономить время компиляции, но если вы сделаете то, что вы предлагаете, вы внезапно окажетесь в прекрасном положении, чтобы выстрелить себе в ногу. Если у вас есть библиотека 1, которая зависит от библиотеки 2, и только изменения библиотеки 2, вы можете подумать, что вы можете создать только измененную библиотеку, но на днях вы собираетесь внести изменения в библиотеку 2, которая сломается библиотека 1, и без сборки библиотеки 2 вы не поймаете ее в компиляции. Так что по моему скромному мнению, НЕ ДЕЛАЙТЕ ЭТОГО.

Причина, по которой это не будет работать в VS2005 и 2008, заключается в том, что VS использует MSBuild. MSBuild работает с файлами проекта и проверяет ссылки проекта и сначала строит все ссылочные проекты, если их источник изменился, перед сборкой целевого проекта. Вы можете проверить это самостоятельно, запустив MSBuild из командной строки для одного проекта, который не изменился, но с измененным ссылочным проектом. Пример:

msbuild ClassLibrary4.csproj

где ClassLibrary4 не изменилась, но она ссылается на ClassLibrary5, который изменился. MSBuild сначала соберет lib 5, прежде чем соберет 4, даже если вы не упомянули 5.

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

Оно того не стоит.

1 голос
/ 23 сентября 2009

У меня тоже была эта проблема, и я заметил эти предупреждения при сборке на Windows 7 x64, VS2008 SP1:

cl: предупреждение командной строки D9038: / ZI не поддерживается на этой платформе; включение / Zi вместо

cl: предупреждение командной строки D9007: '/ Gm' требует '/ Zi'; опция игнорируется

Я изменил свойства своего проекта на:

C / C ++ -> Общие -> Формат отладочной информации = / Zi

C / C ++ -> Генерация кода -> Включить минимальную сборку = Нет

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

1 голос
/ 28 июля 2009

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

0 голосов
/ 14 июня 2014

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

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

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

Ошибка простого отсутствующего файла: у вас могут быть более сложные отношения даты сборки между источником и целью. Вы можете использовать утилиту, чтобы узнать, какой внешний тест запускает сборку. Чтобы получить эту информацию, вы можете включить подробное ведение журнала CPS. См .: Эндрю Арнотт - Включить трассировку системы проектов C ++ и Javascript (http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx). Я использую опцию DebugView. Бесценный инструмент, когда вам это нужно.

(это специфичный для C # вопрос, но другой пост был объединен как идентичный)

...