У меня есть проект С#, который включает в себя один exe и 11 файлов библиотеки. Exe ссылается на все библиотеки, а lib1 может ссылаться на lib2, lib3, lib4 и т.д.
Если я внес изменения в класс в lib1 и построил решение, я предположил, что нужно будет изменить только lib1 и exe. Тем не менее, все dll и exe создаются, если я хочу запустить решение.
Есть ли способ, которым я могу остановить создание зависимостей, если они не были изменены?
Является ли ключ этой фразой? "Однако все dll и exe строятся, если я хочу запустить решение"
Visual Studio всегда будет пытаться создавать все, когда вы запускаете один проект, даже если этот проект не зависит от всего. Однако этот выбор можно изменить. Перейдите в "Инструменты | Параметры | Проекты и решения". "Построить и запустить" и установить флажок "Только создавать проекты запуска и зависимости от Run". Затем, когда вы нажмете F5, VS будет только строить ваш проект запуска и библиотеки DLL, от которых это зависит.
Вы можете отключить опцию сборки для указанных проектов в Конфигурация решения:
SolutionProperties http://i.msdn.microsoft.com/Bb166577.vsSolutionCfg(en-us,VS.90).gif
Вы можете создать свои собственные конфигурации решений для создания конкретных конфигураций проектов...
build config http://i.msdn.microsoft.com/Bb166577.vsConfigManager(en-us,VS.90).gif
Я не уверен, есть ли способ избежать зависимостей от создания. Вы можете найти некоторую информацию здесь, например, установить copylocal в false и поместить DLL в общий каталог.
Оптимизация сборки решений Visual Studio - где разместить DLL файлы?
У нас действительно была эта проблема в моем текущем проекте, в нашем сценарии даже запуск модульных тестов (без каких-либо изменений кода) вызывал перекомпиляцию. Проверьте конфигурацию сборки "Платформа".
Если вы используете "Any CPU", то по какой-то причине он восстанавливает все проекты независимо от изменений. Попробуйте использовать конкретные для процессора сборки, т.е. X86 или x64 (используйте платформу, специфичную для машинной архитектуры вашего компьютера). Работали для нас для сборки x86.
alt text http://labs.episerver.com/Global/xmlrpc/111856/2008/06/24/image_26.png
У нас была аналогичная проблема на работе. В событиях после сборки мы вручную вносили манифесты в выходы в каталоге bin. Visual Studio копировала ссылки на проект из объекта obj dir (которые не были изменены). Разница в метрической шкале вызвала ненужные перестройки.
Если ваши события после сборки изменяют выходные данные проекта, то либо модифицируйте выходы в бункере, либо в OR или OR, скопируйте измененные выходы в каталог bin поверх тех, которые находятся в объекте.
Я просто "исправил" ту же проблему с моим проектом VS. Visual Studio всегда перестраивала, даже если ничего не меняла. Мое решение. Один cs файл имел будущую временную метку (Год 2015, это была моя ошибка). Я открыл файл, сохранил его, и моя проблема была решена.
Теперь, после того, как я это скажу, какая-то пропеллер-голова собирается идти и противоречить мне, но нет способа сделать то, что вы хотите сделать из 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.
Единственный способ обойти все эти failafes - использовать компилятор напрямую, а не проходить через MSBuild. Уродливый, уродливый, но это так. В основном вы будете сведены к повторной реализации MSBuild в той или иной форме, чтобы делать то, что вы хотите сделать.
Это не стоит.
Обратите внимание на следующий сайт для получения более подробной информации о том, когда проект построен, а также различия между сборкой и перестройкой.
У меня тоже была эта проблема, и я заметил эти предупреждения при создании на Windows 7 x64, VS2008 SP1:
cl: Предупреждение командной строки D9038:/ZI не поддерживается на этой платформе; включение /Zi вместо
cl: Предупреждение командной строки D9007: '/Gm' требует '/Zi'; опция игнорируется
Я изменил свои свойства проекта на:
C/С++ → Общие → Формат отладки =/Zi
C/С++ → Генерация кода → Включить минимальную сборку = Нет
После перестройки я переключил их обратно и зависимости снова работают. Но до этого никакая очистка, перестройка или полное удаление выходного каталога не исправит его.
Я не думаю, что вам нужно сделать это из коробки в VS. Вам нужна эта надстройка http://workspacewhiz.com/
Это не бесплатно, но вы можете оценить его, прежде чем покупать.
Да, исключить не изменяющиеся биты из решения. Я говорю это с оговоркой, так как вы можете скомпилировать таким образом, что изменение номера сборки для измененного lib может привести к поломке нестроенных фрагментов. Это не должно быть так, если вы не нарушаете интерфейс, но это довольно часто, потому что большинство разработчиков не понимают интерфейс в мире .NET. Это связано с тем, что не нужно писать IDL.: -)
Что касается X projcts в решении, NO, вы не можете остановить их от создания, так как система видит, что зависимость изменилась.
Кстати, вы должны посмотреть на свой проект и выяснить, почему ваш проект пользовательского интерфейса (предположим, что это пользовательский интерфейс) ссылается на ту же библиотеку, что и все остальное. Хорошая модель зависимости отобразит класс (ы), который должен быть разбит как объекты данных или объекты домена (я сделал предположение, что общая зависимость - это какой-то объект данных или объект домена, конечно, но это довольно часто). Если общая зависимость не является объектом domain/data, тогда я бы переосмыслил свою архитектуру в большинстве случаев. В общем, вы должны иметь возможность создавать путь от пользовательского интерфейса к данным без общих зависимостей, отличных от не поведенческих объектов.
Не уверенный в превосходном способе справиться с этим, но в прошлом, если бы у меня был проект или два, которые продолжали перестраиваться, и предполагая, что я не буду работать в них, я бы отключил процесс сборки для них.
Щелкните правой кнопкой мыши на sln, выберите диспетчер конфигурации и снимите флажки. Не идеально, но работает, когда Visual Studio не ведет себя.
Если вы продолжаете испытывать эту проблему, это может быть связано с отсутствующей или устаревшей рассчитанной зависимостью (например, заголовком), которая указана в вашем проекте, но не существует.
Это происходит со мной особенно часто после перехода на новую версию (например, с 2012 по 2013 год), потому что VS может перераспределять зависимости в процессе преобразования или переходить на новое местоположение.
Быстрая проверка заключается в том, чтобы дважды щелкнуть каждый файл в оскорбительном проекте из браузера решений. Если вы обнаружите, что файл не существует, это ваша проблема.
Не удалось пропустить отсутствующий файл: у вас может быть более сложная взаимосвязь даты создания источника и цели. Вы можете использовать служебную программу, чтобы узнать, какой внешний тест запускает сборку. Чтобы получить эту информацию, вы можете включить подробное ведение журнала CPS. См.: Andrew Arnott - Включить трассировку системы проекта С++ и Javascript (http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx). Я использую параметр DebugView. Бесценный инструмент, когда вам это нужно.
(это конкретный вопрос на С#, но другая запись была объединена как идентичная)
.gif){kind=link}
.gif){kind=link}
