Порядок сборки целевого объекта

6 ответов

Лучший ответ

Rebuild = Clean + Build (обычно)

Примечательные детали:

1. Для решения с несколькими проектами «перестроить решение» выполняет «очистку», за которой следует «сборка» для каждого проекта (возможно, параллельно). Тогда как «чистое решение», за которым следует «решение для сборки», сначала очищает все проекты (возможно, параллельно), а затем строит все проекты (возможно, параллельно). Эта разница в последовательности событий может стать значительной, когда в игру вступят межпроектные зависимости.

2. Все три действия соответствуют целям MSBuild. Таким образом, проект может переопределить действие Rebuild, чтобы сделать что-то совершенно другое.

316

Jon Coombs
22 Ноя 2018 в 06:56

Эрл прав, что 99% времени Rebuild = Clean + Build.

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

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

164

LeopardSkinPillBoxHat
17 Фев 2012 в 03:58

Давайте определим реализацию Rebuild по умолчанию в терминах реализаций Clean и Build по умолчанию:

1. Для каждого проекта: Перестроить проект = Чистый проект + Построить проект.

2. Для решения: перестроить проект sln = foreach в sln (чистый проект + проект сборки).

Обратите внимание, что из-за различий в порядке выполнения Rebuild sln отличается от (Clean sln + Build sln) = (foreach project in sln Clean project) + (foreach project in sln Build project). Кроме того, этот «foreach» может выполняться одновременно, поэтому разные задачи могут выполняться одновременно в двух сценариях

Допустим, у вас есть sln, содержащий proj1, proj2 и proj3.

• Rebuild sln = (Clean proj1 + Build proj1) & (Clean proj2 + Build proj2) & (Чистый proj3 + Build proj3)

• Очистить Sln + Сборка Sln = (Очистить proj1 и Очистить proj2 и Очистить proj3) + (Сборка proj1 и Build proj2 и Build proj3)

+ означает последовательный, & означает одновременный.

Поэтому, если зависимости проекта настроены неправильно, есть вероятность, что при выполнении Rebuild sln некоторые из ваших проектов будут ссылаться на устаревшую библиотеку. Это потому, что не гарантируется, что все чистки будут завершены до начала первой сборки. Если вы выполните Clean sln + Build sln, они выдадут ошибку ссылки и сразу сообщат вам об этом, вместо того, чтобы предоставить вам приложение с необычным поведением.

59

Palec
26 Янв 2020 в 09:12

Из http://www.cs.tufts.edu/r/ graphics / resources / vs_getting_started / vs_getting_started.htm, (просто погуглил):

Сборка означает компиляцию и связывание только исходных файлов, которые изменились с момента последней сборки, в то время как Rebuild означает компиляцию и связывание всех исходных файлов независимо от того, изменились они или нет. Сборка — это нормальное дело, и она выполняется быстрее. Иногда версии целевых компонентов проекта могут рассинхронизироваться, и для успешной сборки требуется повторная сборка. На практике чистка не требуется.

Build or Rebuild Solution создает или перестраивает все проекты в вашем решении, в то время как Build или Rebuild строит или перестраивает проект StartUp, «привет» на снимке экрана выше. Чтобы установить запускаемый проект, щелкните правой кнопкой мыши имя нужного проекта на вкладке «Обозреватель решений» и выберите «Установить как запускаемый проект». Название проекта теперь выделено жирным шрифтом. Поскольку решения для домашних заданий обычно имеют только один проект, Build or Rebuild Solution фактически то же самое, что Build или Rebuild.

Compile просто компилирует исходный файл, редактируемый в данный момент. Полезно для быстрой проверки ошибок, когда остальные исходные файлы находятся в незавершенном состоянии, что может помешать успешной сборке всего проекта. Ctrl-F7 — это горячая клавиша для компиляции.

11

Eduardo Mello
21 Авг 2009 в 13:10

Из этого сообщения в блоге a>, который автор связал как комментарий к этому вопросу:

5

Community
23 Май 2017 в 11:47

Еще одно отличие: Clean очищает результаты теста в обозревателе тестов, а Rebuild — нет.

NoJoshua
5 Мар 2021 в 14:18

Начальные целевые объекты

Атрибут элемента Project указывает целевые объекты, которые будут выполняться первыми, даже если целевые объекты указаны в командной строке или в атрибуте . Начальные целевые объекты обычно используются для проверки ошибок.

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

Импортированные проекты могут иметь собственные атрибуты . Все начальные целевые объекты собираются вместе и выполняются по порядку.

Дополнительные сведения см. в практическом руководстве по выбору цели для первой сборки.

Создание определения сборки для развертывания конкретных сборок

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

В этом случае вы не хотите, чтобы определение сборки действительно выполняло все—, что нужно для выполнения логики развертывания в файле пользовательского проекта. Файл Publish. proj включает условную логику, которая пропускает целевой объект сборки , если файл выполняется в Team Build. Это достигается путем вычисления встроенного свойства буилдингинтеамбуилд , которое автоматически устанавливается в значение true при запуске файла проекта в Team Build. В результате можно пропустить процесс сборки и просто запустить файл проекта для развертывания существующей сборки.

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

1. В Visual Studio 2010 в окне Team Explorer разверните узел командного проекта, щелкните правой кнопкой мыши элемент сборкии выберите пункт создать определение сборки.

2. На вкладке Общие присвойте определению сборки имя (например, деплойтостагинг) и необязательное описание.

3. На вкладке триггер выберите вручную — возвраты не активируют новую сборку.

4. На вкладке сборки по умолчанию в поле Копировать выходные данные сборки в следующую папку сброса введите UNC-путь к транзитной папке (например, \тфсбуилд\дропс).

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

   

   

   

   

   

   

   

   

   

6. В таблице Параметры процесса сборки щелкните в строке элементы для построения , а затем нажмите кнопку с многоточием .

7. В диалоговом окне элементы для построения нажмите кнопку Добавить.

8. В раскрывающемся списке элементы типа выберите файлы проекта MSBuild.

9. Перейдите к расположению файла настраиваемого проекта, в котором вы управляете процессом развертывания, выберите файл и нажмите кнопку ОК.

10. В диалоговом окне элементы для построения нажмите кнопку ОК.

11. В таблице Параметры процесса сборки разверните раздел Дополнительно .

12. В строке Аргументы MSBuild укажите расположение файла проекта для конкретной среды и добавьте заполнитель для расположения папки сборки:

    Note

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

13. Выберите команду Сохранить.

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

Развертывание определенной сборки из определения сборки

1. В окне Team Explorer щелкните правой кнопкой мыши определение сборки и выберите пункт поставить в очередь новую сборку.

2. В диалоговом окне Создание очереди на вкладке Параметры разверните раздел Дополнительно .

3. В строке Аргументы MSBuild замените значение свойства аутпутрут расположением папки сборки. Пример:

   Note

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

4. Щелкните очередь.

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

Этап выполнения

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

Порядок сборки целевого объекта

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

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

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

Ссылки проекта

Существует два пути кода, которые MSBuild может использовать: обычный, описанный здесь, и параметр graph, описанный в следующем разделе.

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

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

Visual Studio позволяет создавать зависимости проектов в файлах решения (SLN). Зависимости указываются в файле решения и учитываются только при создании решения или при построении в Visual Studio. При построении одного проекта зависимость этого типа игнорируется. Ссылки на решения преобразуются в элементы , а затем обрабатываются аналогичным образом.

Параметр Graph

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

Обзор задач

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

Рассмотрим сценарий непрерывной интеграции (CI), описанный в предыдущем разделе Создание определения сборки, поддерживающего развертывание. Вы создали определение сборки в Team Foundation Server (TFS) 2010. Каждый раз, когда разработчик проверяет код в TFS, Team Build выполнит сборку кода, создаст веб-пакеты и скрипты баз данных в рамках процесса сборки, пропустит любые модульные тесты и развернет ресурсы в тестовой среде. В зависимости от политики хранения, настроенной при создании определения сборки, TFS будет хранить определенное число предыдущих сборок.

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

Для этого необходимо сообщить Microsoft Build Engine (MSBuild), где найти веб-пакеты и скрипты базы данных, созданные определенной сборкой.

6 ответов

У меня есть пустое решение и три библиотеки классов , , .

я использую и в библиотека классов.

Затем:

• решение для Сборки Возрастающая сборка и компиляции только файлы, которые изменяются. Если блок не имеет никаких изменений, это, wonвЂt восстановлены. Кроме того, это не удалит промежуточных файлов. Если Изменяют некоторый код в проект библиотеки, то СОЗДАЮТ решение. В ниже снимка экрана, обратитесь к метке времени DLL, EXE обновляется в и библиотека.

• Восстанавливают решение, Удаляет все скомпилированные файлы и компилирует все независимо от изменений, игнорируя что-либо itвЂs, сделанный прежде. Щелкните правой кнопкой по названию решения . То, что это делает, удаляет все блоки, EXEs и отнесенные файлы для компиляции снова.

• Чистое Решение Удаляет все скомпилированные, промежуточные файлы (т.е. EXEs и DLLs) из bin/obj каталога.

ответ дан 19 December 2019 в 20:19

Взято из по этой ссылке :

ответ дан 19 December 2019 в 20:19

• Решение сборки будет выполнять инкрементную сборку: если оно не думает , что ему нужно перестроить проект, оно не будет. Он также может использовать частично построенные части проекта, если они не изменились (я не знаю, как далеко это зайдет)
• Rebuild solution очистит, а затем построит решение с нуля, игнорируя все, что в нем есть. сделано раньше. Разница между этим и «Очистить с последующей сборкой» заключается в том, что Rebuild будет очищать, а затем создавать каждый проект, по одному, а не очищать все и затем создавать все.
• Чистое решение удалит артефакты сборки из предыдущей сборки. Если в целевых каталогах сборки (bin и obj) есть какие-либо другие файлы, их нельзя удалить, но фактические артефакты сборки удаляются. Я видел поведение для этого варианта — иногда удаление было довольно тщательным, а иногда — нет — но пока что я дам VS преимущество сомнения:)

(Ссылки на devenv.exe переключатели командной строки, но они действуют так же, как пункты меню.)

ответ дан 19 December 2019 в 20:19

Решение для сборки — Выполняет сборку любых сборок, в которых были изменены файлы. Если в сборке нет изменений, она не будет перестроена. Также не удаляются промежуточные файлы.

Используется чаще всего.

Решение для восстановления — Восстанавливает все сборки независимо от изменений, но оставляет промежуточные файлы.

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

Чистое решение — Удалить все промежуточные файлы.

Используется, когда ничего не помогает, и вам нужно все очистить и начать заново.

ответ дан 19 December 2019 в 20:19

Решение для сборки построит все проекты в решении, которые были изменены. Rebuild собирает все проекты независимо от того, что, чистое решение удаляет все временные файлы, гарантируя, что следующая сборка будет завершена.

ответ дан 19 December 2019 в 20:19

Я просто думаю, что Rebuild выполняет сначала очистку, а затем сборку. Может я ошибаюсь … комментарии?

ответ дан 19 December 2019 в 20:19

Другие вопросы по тегам:

Открытие проекта из репозитория GitHub с помощью Visual Studio 2019

Способ открытия проектов из репозитория GitHub с помощью Visual Studio зависит от версии. В частности, если вы установили Visual Studio 2019 версии 16.8 или выше, вам доступны новые полностью интегрированные возможности Git.

Но вы всегда можете открыть проект из репозитория GitHub с помощью Visual Studio, какая бы версия у вас ни была.

Visual Studio 2019 версии 16.8 и более поздней

Ниже описано, как можно использовать Git в Visual Studio 2019 версии 16.8 или выше.

Клонирование репозитория GitHub, а затем открытие проекта

1. Запустите Visual Studio 2019.

2. В начальном окне выберите раздел Клонировать репозиторий.

3. Введите или укажите расположение репозитория, а затем нажмите кнопку Клонировать.

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

   Нажмите кнопку Сохранить, чтобы добавить эту информацию в GITCONFIG-файл. (Или нажмите кнопку Отменить, чтобы сделать это позже.)

   Dica

   Дополнительные сведения о входе в Visual Studio см. на странице Вход в Visual Studio. Дополнительные сведения о том, как использовать учетную запись GitHub для входа, см. на странице Работа с учетными записями GitHub в Visual Studio.

   Затем Visual Studio автоматически загрузит и откроет решение из репозитория.

5. Если репозиторий содержит несколько решений, они будут отображаться в обозревателе. Список решений можно просмотреть, нажав кнопку Переключить представления в обозревателе решений.

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

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

   Dica

   Вы также можете использовать меню Git в интегрированной среде разработки Visual Studio, чтобы клонировать репозиторий и открыть проект.

Открытие локального проекта из репозитория GitHub, клонированного ранее

1. Откройте Visual Studio 2019 версии 16.8 или выше.

2. В начальном окне выберите Открыть проект или решение.

   В Visual Studio откроется проводник. Найдите решение или проект и выберите его, чтобы открыть.

   Если вы недавно открывали проект или решение, его можно быстро открыть снова из раздела Открыть последние.

   Dica

   Кроме того, можно использовать меню Git в интегрированной среде разработки Visual Studio, чтобы открывать локальные папки и файлы из репозитория, который ранее клонировали.

   Теперь можно приступать к написанию кода.

Клонирование репозитория GitHub, а затем открытие проекта

1. Откройте Visual Studio 2019 версии 16.7 или ниже.

2. В начальном окне выберите Клонирование или извлечение кода.

3. Введите или укажите расположение репозитория, а затем нажмите кнопку Клонировать.

   Visual Studio откроет проект из репозитория.

4. Если у вас есть файл решения, он будет отображаться в раскрывающемся меню «Решения и папки». Выберите его, и в Visual Studio откроется нужное решение.

   Если в вашем репозитории нет файла решения (а именно SLN-файла), во всплывающем меню будет сообщение «Решения не найдены.». Но вы можете дважды щелкнуть любой файл в меню папок, чтобы открыть этот файл в редакторе кода Visual Studio.

   Теперь можно приступать к написанию кода.

Запуск

MSBuild можно вызывать из Visual Studio с помощью объектной модели MSBuild в Microsoft.Build.dll или путем вызова исполняемого файла непосредственно в командной строке или в сценарии, например в системах CI. В любом случае входные данные, влияющие на процесс сборки, включают файл проекта (или объект проекта, внутренний для Visual Studio), возможно, файл решения, переменные среды и параметры командной строки или их эквиваленты объектной модели. На этапе запуска параметры командной строки или эквиваленты объектной модели используются для настройки параметров MSBuild, таких как параметры средств ведения журнала. Свойства, заданные в командной строке с помощью параметра или , задаются как глобальные свойства, которые переопределяют все значения, которые будут установлены в файлах проекта, даже если файлы проекта считываются позже.

В следующих разделах содержатся сведения о входных файлах, таких как файлы решений или файлы проектов.

Проекты и решения

Экземпляры MSBuild могут состоять из одного проекта или нескольких проектов в составе решения. Файл решения не является XML-файлом MSBuild, но MSBuild интерпретирует его для получения сведений о проектах, которые должны быть созданы для заданной конфигурации и параметров платформы. Когда MSBuild обрабатывает эти входные данные XML, это называется сборкой решения. Он имеет несколько расширяемых точек, которые позволяют выполнять какие-либо действия во всех сборках решения, но поскольку эта сборка является отдельным запуском из сборок отдельных проектов, никакие настройки свойств или целевых определений из сборки решения не важны для каждой отдельной сборки проекта.

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

Сборки Visual Studio и сборки MSBuild.exe

Имеется ряд существенных различий между сборкой проектов в Visual Studio и при вызове MSBuild напрямую либо с помощью исполняемого файла MSBuild, либо при использовании объектной модели MSBuild для запуска сборки. Visual Studio управляет порядком сборки проекта для сборок Visual Studio. Он вызывает только MSBuild на уровне отдельного проекта. Когда это происходит, задаются несколько логических свойств ( и ), которые значительно влияют на то, что делает MSBuild. Внутри каждого проекта выполнение происходит так же, как при вызове с помощью MSBuild, но отличается для проектов, на которые имеются ссылки. В MSBuild, когда требуются проекты, на которые имеются ссылки, возникает фактическая сборка (то есть она запускает задачи и средства и создает выходные данные). Когда сборка Visual Studio находит проект, на который указывает ссылка, MSBuild возвращает ожидаемые выходные данные из упоминаемого проекта. Это позволяет Visual Studio управлять сборкой этих проектов. Visual Studio определяет порядок сборки и вызывает MSBuild отдельно (по мере необходимости), все это полностью находится под контролем Visual Studio.

Другое различие возникает при вызове MSBuild файлом решения, MSBuild анализирует файл решения, создает стандартный входной XML-файл, оценивает его и выполняет в качестве проекта. Сборка решения выполняется перед любым проектом. При сборке из Visual Studio ничего этого не происходит; MSBuild не видит файл решения. Как следствие, настройка сборки решения (с использованием before.SolutionName.sln.targets и after.SolutionName.sln.targets) применяется только к MSBuild.exe или к управляемой объектной модели, а не к сборкам Visual Studio.

Пакеты SDK для проектов

Функция пакета SDK для файлов проекта MSBuild относительно нова. До этого изменения файлы проекта явным образом импортировали файлы TARGETS и PROPS, в которых определен процесс сборки для конкретного типа проекта.

Проекты .NET Core импортируют соответствующую версию пакета SDK для .NET. См. статью Пакеты SDK для проектов .NET Core и ссылку на сведения о свойствах.

Настраиваемые пользователем импорты

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

• Directory.Build.Props
• Directory.Build.targets

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

Файл Directory.Build.props импортируется с помощью Microsoft.Common.props, поэтому в файле проекта доступны определенные свойства. Их можно переопределить в файле проекта для настройки значений на уровне каждого проекта. Файл Directory.Build.targets считывается в файле после файла проекта. Обычно он содержит целевые объекты, но здесь также можно определить свойства, которые не требуется переопределять для отдельных проектов.

Настройка всех сборок .NET

При обслуживании сервера сборки может потребоваться глобально настроить параметры MSBuild для всех сборок на сервере. В принципе, вы можете изменить глобальные файлы Microsoft.Common.Targets или Microsoft.Common.Props, однако существует лучший способ. Вы можете оказать влияние на все сборки определенного типа проекта (например, все проекты C#), используя определенные свойства MSBuild и добавив определенные пользовательские файлы и .

Чтобы повлиять на все сборки C# или Visual Basic, управляемые при установке MSBuild или Visual Studio, создайте файл Custom.Before.Microsoft.Common.Targets или Custom.After.Microsoft.Common.Targets с целевыми объектами, которые будут выполняться до или после Microsoft.Common.targets или файл Custom.Before.Microsoft.Common.Props или Custom.After.Microsoft.Common.Props со свойствами, которые будут обработаны до или после Microsoft.Common.props.

Расположение этих файлов можно указать с помощью следующих свойств MSBuild:

• CustomBeforeMicrosoftCommonProps
• CustomBeforeMicrosoftCommonTargets
• CustomAfterMicrosoftCommonProps
• CustomAfterMicrosoftCommonTargets
• CustomBeforeMicrosoftCSharpTargets
• CustomBeforeMicrosoftVisualBasicTargets
• CustomAfterMicrosoftCSharpTargets
• CustomAfterMicrosoftVisualBasicTargets

Обычные версии этих свойств влияют как на проекты C#, так и на Visual Basic. Эти свойства можно задать в командной строке MSBuild.

Наилучший подход зависит от вашего сценария. Благодаря расширяемости Visual Studio вы можете настроить систему сборки и реализовать механизм для установки настроек и управления ими.

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

Aviso

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

Создание проекта из существующих файлов с текстом программ

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

1. Последовательно выберите Файл > Создать > Project From Existing Code (Проект из существующего кода).

2. В мастере создания проекта по существующим файлам с кодом выберите в раскрывающемся списке Задать тип проекта нужный тип проекта, а затем нажмите Далее.

3. В мастере перейдите к месту хранения файлов и введите имя нового проекта в поле Имя. По завершении нажмите кнопку Готово.

Observação

Этот вариант лучше всего подходит для относительно простой коллекции файлов. Сейчас поддерживаются только типы проектов C++, Apache Cordova, Visual Basic и C#.