Co oznaczają atrybuty "Ogranicznik" i "InheritsFromParent" w plikach .vsprops?

Question

ja nie potrafię znaleźć żadnego przydatnych dokumentacji firmy Microsoft o tym, jak można by wykorzystać Delimiter i InheritsFromParent atrybuty w elemencie UserMacro podczas definiowania makr użytkownika w plikach arkuszy .vsprops własności dla Visual Studio.

Oto próbka Wykorzystanie:

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

Z powyższego przykładu, zgaduję że „dziedziczą” naprawdę oznacza „a) jeżeli definicja jest niepusty następnie dołączyć ogranicznika, oraz b) dołączyć nowa definicja " gdzie jako zachowanie niedziedzicze byłoby po prostu zastąpienie bieżącej definicji makra. Czy ktoś wie na pewno? Nawet lepiej, czy ktoś ma jakieś sugerowane źródło alternatywnej dokumentacji dla plików i makr Visual Studio .vsprops?

UWAGA: to nie taka sama jak atrybutu elementu VisualStudioPropertySheetInheritedPropertySheets, na przykład:

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

W tym przypadku "dziedziczą" zasadzie oznacza "obejmują".

Answer 1

[Odpowiadając na moje własne pytanie]

InheritsFromParent oznacza prepend. Aby to sprawdzić, zrobiłem eksperyment, który pokazuje, jak Makra Użytkownika pracować w Visual Studio 2008. Oto konfiguracja:

• Projekt p.vcproj zawiera plik arkuszy nieruchomość d.vsprops („d” dla pochodzący) przy użyciu znacznika InheritedPropertySheets .
• d.vsprops zawiera plik arkuszy nieruchomość b.vsprops („b” dla bazy.)
• p.vcproj definiuje również wydarzenie Gotowy który zrzuca środowiska.
• Oba pliki: .vsprops zawierają definicje makr użytkownika.

b.vsprops

... 
<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"/> 
... 

s.vcproj

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

wyjście build

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

Na podstawie tych wyników można stwierdzić, co następuje:

1. PerformEnvironmentSet="true" jest konieczne dla makra użytkownika, które zostaną określone w warunkach stosowanych do produkcji wydarzenia. Dowód: NOENV niewidoczny w wynikach kompilacji.
2. Makra użytkownika są zawsze odziedziczone zawartych arkuszy własności niezależnie od PerformEnvironmentSet lub InheritsFromParent. Dowód: w b.vsprops, NOENV nie jest ustawiony w środowisku i w d.vsprops jest używany bez potrzeby InheritsFromParent.
3. Prosta redefinicja makra użytkownika przesłania dowolnej poprzedniej definicji. Dowód: OVERRIDE jest ustawiony na D, chociaż wcześniej został zdefiniowany jako B.
4. Weryfikacja makro użytkownika z InheritsFromParent="true"Poprzedza nowa definicja do każdej poprzedniej definicji, oddzielonych określonym Delimiter. Dowód: PREPEND jest ustawiony na D+B

Oto kilka dodatkowych zasobów znalazłem do wyjaśnienia Visual Studio .vsprops plików i pokrewne tematy, to od kilku lat wstecz, ale wciąż jest pomocny (nie D lub B+D.):

understanding the VC project system part I: files and tools

understanding the VC project system part II: configurations and the project property pages dialog

understanding the VC project system part III: macros, environment variables and sharing

understanding the VC project system part IV: properties and property inheritance

understanding the VC project system part V: building, tools and dependencies

understanding the VC project system part VI: custom build steps and build events

understanding the VC project system part VII: "makefile" projects and (re-)using environments

Answer 2

Istnieje dokumentacja dotycząca wersji interfejsu użytkownika tego here. Wiele plików XML wydaje się nieco nieudokumentowanych, często po prostu dając schema file. Twoje przypuszczenie o tym, jak działają, jest w porządku.

Answer 3

To nie jest cała historia.

• Ograniczniki nie są dziedziczone. Tylko lista elementów, które ograniczają, jest dziedziczona: te same makra użytkownika mogą mieć różne ograniczniki w różnych arkuszach właściwości, ale używany jest tylko ostatni napotkany ogranicznik. (Piszę "ostatni z napotkanych", ponieważ na poziomie projektu nie możemy określić ogranicznika i użyto tam ostatniego arkusza właściwości, który określił dziedziczenie dla tego makra)
• Ograniczniki działają tylko wtedy, gdy są wykonane z pojedynczego znaku o wartości .Ogranicznik dłuższy o niż jeden znak może mieć swój pierwszy i/lub ostatni znak pozbawiony w niektórych przypadkach, w błędnej próbie , aby "dołączyć" listę wartości.
• Wydaje się, że $ (Dziedziczone) działa wewnątrz makr użytkownika . Podobnie jak w przypadku właściwości agregujących
  , działa on jako symbol zastępczy dla wartości rodzica i może pojawiać się wiele razy. Jeśli nie zostanie znaleziony $ (Dziedziczony), jest on domyślnie na początku, jeśli ustawiona jest flaga dziedziczenia.
• $ (NoInherit) również działa w makrach użytkownika (sprawia, że ​​VC zachowuje się tak, jakby pole wyboru było odznaczone).
• Makra użytkownika (i niektóre wbudowane) pojawiają się do pracy, gdy są używane do budowy ścieżki arkusza właściwości (własny konwerter projektu VC korzysta z tej funkcji). Wartość przyjęta przez makra użytkownika w tej sytuacji nie jest jednak zawsze intuicyjna, zwłaszcza jeśli zostanie zmieniona na nowo w innych dołączonych arkuszach właściwości.
• Ogólnie rzecz ujmując, "odziedziczone" lub łączone są formuły, a nie wartości (np. Nie można użyć makra użytkownika do zrobienia migawki lokalnej wartości (np.) $ (IntDir) w arkuszu właściwości i mamy nadzieję, że " bańka "tę wartość przez dziedziczenie, ponieważ to, co zostanie odziedziczone, jest w rzeczywistości formułą" $ (IntDir) ", której wartość zostanie ostatecznie rozwiązana na poziomie projektu/config/pliku).
• Arkusz nieruchomość już załadowany jest ignorowany (wydaje się uniknąć, że ten sam arkusz właściwości ma swoje makra użytkownika zagregowane dwukrotnie)
• Zarówno „/” i „\” wydaje się działać w ścieżek arkusza właściwości (aw najbardziej miejsca, w których VS oczekuje ścieżki).
• Ścieżka arkusza właściwości rozpoczynająca się od "/" (po rozwiązaniu makr) jest przyjmowana jako "./", gdzie "." to lokalizacja wywołującego arkusza/projektu ). To samo, jeśli ścieżka nie zaczyna się od "./", "../" lub "drive: /" (dunno o UNC).