Не привязаны файлы проекта

Обновлено: 05.07.2024

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

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

А потом я заметил одно отличие в файлах *.csproj. Мой проблемный проект не имел следующих данных XML:

Когда я добавил Эти строки, проблема была решена.

1 ответ

Microsoft Visual Studio использует XML для сохранения файлов проекта .vcproj . Таким образом, различать файлы проекта XML должно быть легко. К сожалению, если вы изменяете какие-либо свойства файла проекта, Visual Studio настаивает на случайном перетасовке узлов XML файла проекта! Это делает.

Это происходит потому, что в файле решения содержится информация о системе управления версиями, и файл .csproj просто реализует то, что говорит ему файл решения.

SAK ссылается на "Should Already Know", извлекая информацию из файла решения. Файл решения должен содержать что-то похожее на то, что показано ниже

Теперь может случиться так, что если человек, впервые проверяющий решение и проекты, не включает файл Solution.vssscc, то Visual Studio не сможет определить систему управления версиями. в этом случае удалите файл vssscc и закройте решение. повторное открытие решения создаст новый файл vssscc, убедитесь, что он будет возвращен в систему управления версиями.

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

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

Определение подходящего метода связывания

Решение о применении неявного или явного связывания принимается на уровне архитектуры приложения. Каждый из этих способов имеет свои преимущества и недостатки.

Неявное связывание

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

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

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

Наконец, система изменяет код исполняемого файла процесса и предоставляет функциям DLL начальные адреса.

Как и в случае с остальном кодом программы, загрузчик сопоставляет код DLL в адресном пространстве процесса при запуске процесса. Операционная система загружает его в память только при необходимости. В связи с этим атрибуты кода PRELOAD и LOADONCALL , которые использовались DEF-файлами для управления загрузкой в предыдущих версиях Windows, более не имеют смысла.

Явное связывание

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

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

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

Процесс с неявным связыванием также завершается, если в любой из связанных библиотек DLL функция DllMain завершается сбоем. Процесс с явным связыванием в таких ситуациях не завершается.

Приложение, в котором применяется неявное связывание с множеством библиотек DLL, может долго запускаться, поскольку операционная система Windows при загрузке приложения загружает все библиотеки DLL. Чтобы ускорить процесс запуска приложения, можно выполнять неявное связывание только с теми библиотеками DLL, которые необходимы непосредственно после загрузки. Другие библиотеки DLL могут загружаться позднее по мере необходимости посредством явного связывания.

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

При использовании явного связывания следует учитывать два потенциально опасных фактора:

Если библиотека DLL имеет функцию точки входа DllMain , операционная система вызывает функцию в контексте потока, который вызывал LoadLibrary . Функция точки входа не вызывается, если библиотека DLL уже связана с процессом в рамках предыдущего вызова LoadLibrary , во время которого не выполнялся соответствующий вызов функции FreeLibrary . При явном связывании могут возникать проблемы, если библиотека DLL использует функцию DllMain для инициализации каждого потока в процессе, поскольку все потоки, существовавшие на момент вызова LoadLibrary (или AfxLoadLibrary ), не инициализируются.

Если в библиотеке DLL статические элементы данных объявляются как __declspec(thread) , при явном связывании может произойти сбой системы защиты. После загрузки библиотеки DLL посредством вызова LoadLibrary сбой системы защиты будет происходить каждый раз, когда в коде используется ссылка на такие данные. Статические элементы данных включают как глобальные, так и локальные статические элементы. Поэтому при создании библиотеки DLL не рекомендуется использовать локальную память потока. Если это все же необходимо, следует проинформировать пользователей библиотеки о возможных проблемах при ее динамической загрузке. Дополнительные сведения см. в разделе Использование локальной памяти потока в библиотеке динамической компоновки (пакет SDK для Windows).

Использование неявного связывания

Чтобы использовать библиотеку DLL посредством неявного связывания, исполняемые файлы клиента должны получить от ее поставщика следующие файлы:

Один или несколько файлов заголовка (с расширением h), в которых содержатся объявления экспортированных данных, функций и классов C++ в библиотеке DLL. Все классы, функции и данные, экспортируемые из библиотеки DLL, должны быть отмечены в файле заголовка как __declspec(dllimport) . Дополнительные сведения см. в статье dllexport, dllimport.

Библиотека импорта, которая связывается с исполняемым файлом. Библиотека импорта создается компоновщиком при построении DLL. Дополнительные сведения см. в разделе Использование LIB-файлов в качестве входных данных для компоновщика.

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

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

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

Явное связывание с библиотекой DLL

Чтобы использовать библиотеку DLL посредством явного связывания, необходимо вызвать функцию для явной загрузки библиотеки DLL во время выполнения. Для явного связывания с библиотекой DLL приложение должно выполнить следующие действия:

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

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

По завершении работы с библиотекой DLL вызовите FreeLibrary.

В приведенном ниже примере функции вызывается LoadLibrary для загрузки библиотеки MyDLL, затем вызывается GetProcAddress для получения указателя на функцию DLLFunc1, далее вызывается эта функция и сохраняется результат, после чего вызывается FreeLibrary для выгрузки библиотеки DLL.

В отличие от этого примера, в большинстве случаев LoadLibrary и FreeLibrary следует вызывать в приложении только один раз для нужной библиотеки DLL. Это особенно важно, если вы планируете многократно вызывать функции в библиотеке DLL.

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

Связывание файлов в Project

Создайте в Project отдельные файлы для каждого подпроекта, а затем откройте или создайте проект, который нужно сделать главным.

В главном проекте нажмите Вид > Диаграмма Ганта.

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

Выберите Проект > Подпроект.

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

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

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

Как избежать дублирования имен ресурсов в связанных проектах

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

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

Reorganizing subprojects in the master project

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

Выберите ">Гэтта".

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

Щелкните правой кнопкой мыши и выберите "Вырезать", чтобы удалить вставленный проект.

Примечание: Когда задача вырезана и вставлялась, ее уникальный идентификатор (отличается от столбца идентификатор задачи в левом столбце таблицы "Запись") при ее вхождении в список задач в другом месте. Чтобы переместить задачу без изменения уникального ИД, перетащите задачу на новое место в списке задач. Чтобы перетащить задачу, на поместите указатель на ее ИД в поле "ИД". Когда задача превратилась в четырехконечную стрелку, перетащите ее на новое место. Эти данные будут удалены из плана проекта, но не будут удалены до тех пор, пока вы не в сможете в него вернуться.

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

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

Эти инструкции относятся к Microsoft Project 2007.

Когда следует использовать перекрестные связи между проектами, а не зависимости?

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

Откройте проекты с задачами, которые вы хотите связать.

В одном из проектов откройте меню Окно и выберите Упорядочить все.

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

Щелкните "Сведения " и перейдите на вкладку "Предшественники".

В столбце "ИД" введите имя проекта и номер задачи внешнего предшественника через заглавную сетку. Например, введите "Проект1\1" для задачи "ИД 1" в файле с именем "Проект1".

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

Для установления связи с внешней задачей оба проекта следует предварительно сохранить.

При связываке задач из разных проектов, которые хранятся в Microsoft Office Project Server, необходимо правильно отформатировать и отформатировать задачу-предшественник. В диалоговом окне "Сведения о задаче" на вкладке "Предшественники" в столбце "ИД" необходимо отформатировать задачу, как показано в следующем примере: <>\project1\42. В этом примере project1 — это название проекта, содержаного предшественника, а 42 — ее ИД.

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

Задачи из разных проектов связаны, но данные отличаются

При использовании параметра "Вставлять связь" в диалоговом окне "Специальная вставлять"(меню "Правка") для подключения задач Project использует функцию "Связь с объектами" и "Embedding" (OLE). Связываются только выбранные поля. Однако с задачей может быть связано множество других полей сведений, которые влияют на ее план, и эти поля могут быть скрыты при просмотре в режиме разделенного экрана.

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

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

Сегодня я обновил Visual Studio 2017 до 15.4.2 и обнаружил, что проекты, поставляемые с SQL Server Data Tools (SSDT) 15.4.0 preview, больше не доступны, что является обычным явлением после обновления. Я отремонтировал установку SSDT, чтобы обнаружить, что проекты не вернулись, затем я снова установил ее, и теперь проекты были доступны.

Теперь, когда я открываю существующее решение, содержащее 19 проектов служб reporting services, мне было предложено обновить их, но у меня не было этого приглашения с тех пор, как я использовал предварительный просмотр в первом выпуске. Я пошел дальше и обновил все проекты, добавил новый отчет в проект и внес изменения в свой репозиторий TFVC в Team Services.

Теперь всякий раз, когда я открываю это решение, мне предлагается сделать это для каждого проекта:

Если я использую привязку решения, это работает до тех пор, пока я не закрою решение, а затем мне снова будет предложено сделать то же самое. Если я решу удалить привязки решения и снова связать их с помощью File > Source Control > Advanced > Change Source Control, как только решение будет сохранено и закрыто, я получу то же самое приглашение.

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

2 ответа

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

На данный момент мне удалось решить эту проблему, выполнив следующие действия

Удалить Visual Studio 2017 15.4.2 и SQL Server Data Tools (SSDT) 15.4.0 предварительный просмотр
Установить Visual Studio 2017 15.3.5
Установка SQL Server Data Tools (SSDT) 15.4.0 предварительный просмотр
Удаление проектов служб Microsoft Reporting Services 1.17 в расширениях и обновлениях
Установите Microsoft Reporting Services Projects 1.18 в расширениях и обновлениях

Я обнаружил, что после обновления Visual Studio 2017 до 15.4.2 ни один из проектов бизнес-аналитики не доступен. Microsoft Reporting Services Projects 1.18 указан в разделе Расширения и обновления, но мне пришлось переустановить его, чтобы открыть проекты.

Следующие шаги решили эту проблему для меня:

Обновите Microsoft Visual Studio 2017 до v15.5.2
Обновите проекты служб Microsoft Reporting Services до v1.20

Соглашения об именовании файлов проекта

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

Используйте расширение proj при создании файла проекта, который строит проекты.
Используйте расширение TARGETS при создании файла проекта с возможностью повторного использования для импорта в другие файлы проекта. Файлы с расширением TARGETS обычно не создают ничего сами, они просто содержат инструкции, которые можно импортировать в proj-файлы.

Интеграция с технологиями развертывания

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

Хорошая новость состоит в том, что можно воспользоваться преимуществами точек интеграции, предоставляемых конвейером WPP при создании пользовательских файлов проектов для веб-проектов. Инструкции по развертыванию можно включить в файл проекта, который позволяет создавать проекты, создавать пакеты веб-развертывания и устанавливать эти пакеты на удаленных серверах с помощью одного файла проекта и одного вызова в MSBuild. Кроме того, в процессе сборки можно вызывать любые другие исполняемые файлы. Например, можно запустить программу командной строки VSDBCMD. exe для развертывания базы данных из файла схемы. В рамках этого раздела вы узнаете, как можно воспользоваться преимуществами этих возможностей в соответствии с требованиями сценариев корпоративного развертывания.

Структура файла проекта

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

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

Это показывает связь между ключевыми элементами в файле проекта MSBuild:

Элемент Project

Элемент Project является корневым элементом каждого файла проекта. Помимо определения схемы XML для файла проекта, элемент Project может включать атрибуты для указания точек входа для процесса сборки. Например, в образце решения диспетчера контактовфайл Publish. proj указывает, что сборка должна начаться с вызова целевого объекта с именем фуллпублиш.

Свойства и условия

Для успешной сборки и развертывания проектов файл проекта обычно должен предоставлять множество различных частей информации. Эти сведения могут включать в себя имена серверов, строки подключения, учетные данные, конфигурации сборки, пути к исходному и целевому файлам, а также любые другие сведения, которые необходимо включить в настройку поддержки. В файле проекта свойства должны быть определены в элементе PropertyGroup . Свойства MSBuild состоят из пар "ключ-значение". В элементе PropertyGroup имя элемента определяет ключ свойства, а содержимое элемента определяет значение свойства. Например, можно определить свойства с именами ServerName и ConnectionString для хранения статического имени сервера и строки подключения.

Чтобы получить значение свойства, используйте формат $ (PropertyName) . Например, чтобы получить значение свойства ServerName , введите:

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

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

Дополнительные сведения о аргументах и параметрах, которые можно использовать с MSBuild. exe, см. в справочнике по командной строке MSBuild.

Для получения значений переменных среды и встроенных свойств проекта можно использовать тот же синтаксис свойств. Многие часто используемые свойства определены для вас, и их можно использовать в файлах проекта, включив соответствующее имя параметра. Например,—чтобы получить текущую платформу проекта, например, x86 или AnyCpu—, можно включить ссылку на свойство $ (Platform) в файл проекта. Дополнительные сведения см. в статьях макросы для команд и свойств сборки, Общие свойства проекта MSBuildи зарезервированные свойства.

Свойства часто используются в сочетании с условиями. Большинство элементов MSBuild поддерживают атрибут Condition , который позволяет указать критерии, по которым MSBuild должен оценивать элемент. Например, рассмотрим следующее определение свойства:

Когда MSBuild обрабатывает это определение свойства, сначала он проверяет, доступно ли значение свойства $ (аутпутрут) . Если значение свойства не задано—другими словами, пользователь не предоставил значение для этого свойства—, условие вычисляется как true , а значение свойства равно .. \Публиш\аут. Если пользователь предоставил значение для этого свойства, условие вычисляется как false , а значение статического свойства не используется.

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

Элементы и группы элементов

Одной из важных ролей файла проекта является определение входных данных для процесса сборки. Как правило, эти входные—данные представляют собой файлы кода, файлы конфигурации, командные файлы и любые другие файлы, которые необходимо обработать или скопировать в ходе процесса сборки. В схеме проекта MSBuild эти входные данные представлены элементами Item . В файле проекта элементы должны быть определены в элементе ItemGroup . Так же, как и элементы свойств , можно присвоить имя элементу Item , но вам нравится. Однако необходимо указать атрибут include , чтобы определить файл или подстановочный знак, представляемый элементом.

Если указать несколько элементов элементов с одинаковым именем, вы фактически создаете именованный список ресурсов. Хорошим способом увидеть это в действии является просмотр в одном из файлов проекта, создаваемых Visual Studio. Например, файл ContactManager. MVC. csproj в примере решения включает множество групп элементов, каждый из которых имеет несколько одинаково именованных элементов Item .

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

Элементы Item также могут включать дочерние элементы ItemMetadata . Это определяемые пользователем пары "ключ-значение", которые по сути представляют свойства, относящиеся к этому элементу. Например, многие элементы Compile в файле проекта включают дочерние элементы DependentUpon .

Помимо метаданных элементов, созданных пользователем, всем элементам назначаются различные общие метаданные при создании. Дополнительные сведения см. в разделе Стандартные метаданные элементов.

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

Целевые объекты и задачи

В схеме MSBuild элемент Task представляет отдельную инструкцию сборки (или задачу). В состав MSBuild входит множество стандартных задач. Пример:

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

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

Кроме того, можно добавить к элементу проекта атрибут DefaultTargets , чтобы указать целевые объекты, которые требуется вызвать.

В этом случае не нужно указывать целевой объект из командной строки. Можно просто указать файл проекта, и MSBuild будет вызывать целевой объект фуллпублиш .

Целевые объекты и задачи могут включать атрибуты Condition . Таким образом, при выполнении определенных условий можно пропустить все целевые объекты или отдельные задачи.

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

Чтобы использовать значение свойства, введите $ (PropertyName) , где PropertyName — имя элемента Свойства или имя параметра.
Чтобы использовать элемент, введите @ (ItemName) , где ItemName — это имя элемента Item .

Помните, что при создании нескольких элементов с одинаковым именем вы создаете список. Если же вы создаете несколько свойств с одним и тем же именем, Последнее предоставленное значение свойства перезаписывает все предыдущие свойства с тем же именем—, а свойство может содержать только одно значение.

Например, в файле Publish. proj в примере решения Взгляните на целевой объект буилдпрожектс .

В этом примере можно наблюдать за следующими ключевыми точками:

Если параметр буилдингинтеамбуилд указан и имеет значение true, то ни одна из задач в этом целевом объекте не будет выполнена.

Целевой объект содержит один экземпляр задачи MSBuild . Эта задача позволяет создавать другие проекты MSBuild.

Элемент ProjectsToBuild передается задаче. Этот элемент может представлять список файлов проекта или решения, определенный элементами ProjectsToBuild Item в группе элементов. В этом случае элемент ProjectsToBuild ссылается на один файл решения.

Значения свойств, передаваемые в задачу MSBuild , включают параметры с именами аутпутрут и Configuration. Они устанавливаются в значения параметров, если они предоставлены, или на значения статических свойств, если это не так.

Также можно увидеть, что задача MSBuild вызывает целевой объект с именем Build. Это один из нескольких встроенных целевых объектов, широко используемых в файлах проектов Visual Studio и доступных в пользовательских файлах проекта, таких как Сборка, Очистка, Перестроениеи Публикация. Дополнительные сведения об использовании целевых объектов и задач для управления процессом сборки, а также о задачах MSBuild в частности, см. Далее в этом разделе.

Дополнительные сведения о целевых объектах см. в разделе целевые объекты MSBuild.

Разделение файлов проекта для поддержки нескольких сред

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

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

Publish. proj, которая содержит свойства, элементы и целевые объекты, общие для всех сред.
Env-dev. proj, которая содержит свойства, характерные для среды разработки.

Теперь обратите внимание, что файл Publish. proj включает элемент Import сразу под открывающим тегом проекта .

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

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

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

Рекомендации по настройке файлов проекта для конкретной среды сервера см. в разделе Настройка свойств развертывания для целевой среды.

Заключение

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

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

Дополнительные материалы

Читайте также: