Что означают атрибуты Delimiter и InheritsFromParent в файлах .vsprops?

Question

Я не могу найти какую-либо полезную документацию от Microsoft о том, как можно использовать атрибуты Delimiter и InheritsFromParent в элементе UserMacro при определении пользовательских макросов в свойстве .vsprops листы для Visual Studio.

Вот пример использования:

<UserMacro Name="INCLUDEPATH" Value="$(VCROOT)\Inc"
    InheritsFromParent="TRUE" Delimiter=";"/>

Из приведенного выше примера, я предполагаю, что «наследовать» действительно означает «а) если определение не пусто, то добавить разделитель, и б) добавить новое определение» где как ненаследующее поведение будет просто заменить любое текущее макроопределение. Кто-нибудь знает наверняка? Более того, есть ли у кого-нибудь предлагаемый источник альтернативной документации для файлов и макросов Visual Studio .vsprops?

ПРИМЕЧАНИЕ: не совпадает с атрибутом InheritedPropertySheets элемента VisualStudioPropertySheet, например:

<VisualStudioPropertySheet ... InheritedPropertySheets=".\my.vsprops">

В этом случае «наследовать» в основном означает «включать» .

Answer 1

[Отвечая на мой вопрос]

InheritsFromParent означает предварение. Чтобы убедиться в этом, я провел эксперимент, который показывает, как работают пользовательские макросы в Visual Studio 2008. Вот настройка:

• Проект p.vcproj содержит файл листа свойств d.vsprops ('d' для производное ) с использованием тега InheritedPropertySheets.
• d.vsprops включает файл листа свойств b.vsprops ('b' для base .)
• p.vcproj также определяет событие Pre-Build, которое сбрасывает среду.
• Оба .vsprops файла содержат определения макросов пользователя.

b.vsprops * ** 1030 1031 * ... <UserMacro Name="NOENV" Value="B"/> <UserMacro Name="OVERRIDE" Value="B" PerformEnvironmentSet="true"/> <UserMacro Name="PREPEND" Value="B" PerformEnvironmentSet="true"/> ... d.vsprops

...
<VisualStudioPropertySheet ... InheritedPropertySheets=".\b.vsprops">
<UserMacro Name="ENV" Value="$(NOENV)" PerformEnvironmentSet="true"/>
<UserMacro Name="OVERRIDE" Value="D" PerformEnvironmentSet="true"/>
<UserMacro Name="PREPEND" Value="D" InheritsFromParent="true"
    Delimiter="+" PerformEnvironmentSet="true"/>
...

p.vcproj

...
<Configuration ... InheritedPropertySheets=".\d.vsprops">
<Tool Name="VCPreBuildEventTool" CommandLine="set | sort"/>
...

сборка вывода

...
ENV=B
OVERRIDE=D
PREPEND=D+B
...

Из этих результатов можно сделать следующие выводы:

1. PerformEnvironmentSet="true" необходимо для определения пользовательских макросов в среде, используемой для событий сборки. Доказательство: NOENV не отображается в выводе сборки.
2. Макросы пользователя всегда наследуются от включенных листов свойств независимо от PerformEnvironmentSet или InheritsFromParent. Доказательство: в b.vsprops, NOENV не задано в среде, а в d.vsprops оно используется без необходимости InheritsFromParent.
3. Простое переопределение пользовательского макроса переопределяет любое предыдущее определение. Доказательство: OVERRIDE установлено на D, хотя ранее оно было определено как B.
4. Переопределение пользовательского макроса с помощью InheritsFromParent="true" добавляет новое определение к любому предыдущему определению, разделенному указанным Delimiter. Доказательство: PREPEND установлено на D+B (не D или B+D.)

Вот некоторые дополнительные ресурсы, которые я нашел для объяснения файлов Visual Studio .vsprops и связанных с ними тем, это несколько лет назад, но все еще полезно:

понимание части I системы проекта VC: файлы и инструменты

понимание системы II проекта VC: диалог настроек и страниц свойств проекта

понимание системы III проекта VC: макросы, переменные среды и совместное использование

понимание системы IV проекта VC: свойства и наследование свойств

понимание части V системы проекта VC: создание, инструменты и зависимости

понимание части VI системы проекта VC: пользовательские этапы сборки и события сборки

понимание части VII системы проектов VC: проекты "makefile" и (пере) использование сред

Answer 2

Это не вся история.

• Разделители не наследуются. Только список элементов, которые они разделяют, наследуется: одни и те же пользовательские макросы могут иметь разные разделители в разных листах свойств, но используется только последний встреченный разделитель. (Я пишу «последний встреченный», потому что на уровне проекта мы не можем указать разделитель, и что используется, так это последний лист свойств, в котором указано наследование для этого макроса)
• Разделители работают, только если сделаны из один символ Разделитель длиннее чем один персонаж может иметь его первый и / или последний символ в некоторых случаях по ошибке «присоединиться» к списку значений.
• $ (Inherit) работает внутри пользовательские макросы. Как для совокупности
  свойства, он работает как заполнитель для
  родительские значения, и это может появиться несколько раз. Когда $ (Inherit) не найдено, в начале подразумевается, если установлен флаг наследования.
• $ (NoInherit) также, кажется, работает в макросах пользователя (заставляет VC вести себя так, как будто флажок снят).
• Появляются пользовательские макросы (и некоторые встроенные) работать при использовании для построения пути листа свойств (эта функция используется в собственном конвертере проектов VC). Значение Принятые пользователем макросы в этой ситуации не всегда интуитивно понятный, особенно если он переопределен в других включенных таблицах свойств.
• В общем, то, что «наследуется» или объединяется, это формулы, а не значения (т. Е. Вы не можете использовать пользовательский макрос, чтобы сделать снимок локального значения (скажем) $ (IntDir) в листе свойств и надеяться на это » пузырить «это значение через наследование, потому что на самом деле наследуется формула« $ (IntDir) », значение которой в конечном итоге будет разрешено на уровне проекта / конфигурации / файла).
• Уже загруженный лист свойств игнорируется (похоже, во избежание того, что на одном и том же листе свойств пользовательские макросы агрегируются дважды)
• Кажется, что "/" и "\" работают в пути листа свойств (и в большинстве места, где VS ожидает путь).
• Путь к листу свойств, начинающийся с «/» (после разрешения макросов) предполагается в «./», где «. ' это местоположение вызов лист / проект). То же самое, если путь не начинается с "./", "../" или "диск: /" (не знаю о UNC).

Answer 3

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