visual-studio - para - visual studio code mejores plugins

¿Qué significan los atributos ''Delimiter'' e ''InheritsFromParent'' en los archivos.vsprops?

Question

Parece que no puedo encontrar ninguna documentación útil de Microsoft sobre cómo se usarían los atributos UserMacro en el elemento UserMacro al definir Macros de usuario en archivos de hojas de propiedades .vsprops para Visual Studio.

Aquí está el uso de la muestra:

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

Del ejemplo anterior, supongo que "heredar" realmente significa "a) si la definición no está vacía, luego anexar delimitador, yb) anexar nueva definición" mientras que el comportamiento no heredado sería simplemente reemplazar cualquier macro actual definición. ¿Alguien sabe con seguridad? Mejor aún, ¿alguien tiene alguna fuente sugerida de documentación alternativa para archivos y macros de Visual Studio .vsprops ?

NOTA: esto no es lo mismo que el atributo InheritedPropertySheets del elemento VisualStudioPropertySheet , por ejemplo:

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

En este caso, "heredar" significa básicamente "incluir" .

Answer 1

Hay documentación sobre la versión de la interfaz de usuario de esto aquí . Muchos de los archivos XML parecen algo indocumentados, a menudo simplemente dando un archivo de esquema . Su suposición sobre cómo funcionan es más o menos la correcta.

Answer 2

[Respondiendo mi propia pregunta]

InheritsFromParent significa antepender. Para verificar esto, realicé un experimento que revela cómo funcionan las macros de usuario en Visual Studio 2008. Aquí está la configuración:

• El proyecto p.vcproj incluye el archivo de hoja de propiedades d.vsprops (''d'' para derivado ) utilizando la etiqueta InheritedPropertySheets .
• d.vsprops incluye el archivo de hoja de propiedades b.vsprops (''b'' para base ).
• p.vcproj también define un evento de p.vcproj que vuelca el entorno.
• Ambos archivos .vsprops contienen definiciones de Macro de usuario.

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

p.vcproj

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

construir la salida

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

A partir de estos resultados podemos concluir lo siguiente:

1. PerformEnvironmentSet="true" es necesario para que las macros de usuario se definan en el entorno utilizado para los eventos de compilación. Prueba: NOENV no se muestra en la salida de compilación.
2. Las macros de usuario siempre se heredan de las hojas de propiedades incluidas independientemente de PerformEnvironmentSet o PerformEnvironmentSet . Prueba: en b.vsprops , NOENV no está configurado en el entorno y en d.vsprops se usa sin necesidad de InheritsFromParent .
3. La redefinición simple de una macro de usuario anula cualquier definición previa. Prueba: OVERRIDE se establece en D aunque se definió anteriormente como B
4. La redefinición de una macro de usuario con InheritsFromParent="true" antepone la nueva definición a cualquier definición previa, separada por un Delimiter especificado. Prueba: PREPEND se establece en D+B (no D o B+D ).

Aquí hay algunos recursos adicionales que encontré para la explicación de archivos .vsprops de Visual Studio y temas relacionados, es de hace unos años pero sigue siendo útil:

entender el sistema de proyectos de VC parte I: archivos y herramientas

entendiendo el sistema de proyecto de VC parte II: configuraciones y el diálogo de páginas de propiedades del proyecto

comprender el sistema de proyectos de VC parte III: macros, variables de entorno y compartir

comprender el sistema de proyectos de VC, parte IV: propiedades y herencia de propiedades

entender el sistema de proyectos de VC, parte V: construcción, herramientas y dependencias

comprender el sistema de proyectos de VC, parte VI: pasos de compilación personalizados y eventos de compilación

entendiendo el sistema de proyectos de VC parte VII: proyectos de "makefile" y (re) uso de entornos

Answer 3

No es toda la historia.

• Los delimitadores no son heredados. Solo la lista de elementos que delimitan se hereda: las mismas macros de usuario pueden tener diferentes delimitadores en diferentes hojas de propiedades, pero solo se utiliza el último delimitador encontrado. (Escribo "último encuentro" porque a nivel de proyecto, no podemos especificar un delimitador y lo que se usa allí es la última hoja de propiedades que especificó la herencia para esa macro)
• Delimiters funciona solo si está hecho de un solo personaje. Un delimitador de más de un carácter puede tener su primer y / o último carácter despojado en algunos casos, en un intento erróneo de "unirse" a la lista de valores.
• $ (Heredar) parece funcionar dentro de macros de usuario. Me gusta para agregado
  propiedades, funciona como un marcador de posición para
  los valores de los padres, y puede aparecer varias veces. Cuando no se encuentra $ (Heredar), está implícito al principio si se establece el indicador de herencia.
• $ (NoInherit) también parece funcionar en las macros del usuario (hace que VC se comporte como si la casilla no estuviera marcada).
• Las macros de usuario (y algunas integradas) parecen funcionar cuando se usan para construir una ruta de hoja de propiedades (el propio convertidor de proyecto de VC usa esa característica). El valor tomado por las macros del usuario en esta situación no siempre es intuitivo, especialmente si se redefine en otras hojas de propiedades incluidas.
• En general, lo que se "hereda" o concatena son fórmulas y no valores (es decir, no se puede usar una macro de usuario para tomar una instantánea del valor local de (decir) $ (IntDir) en una hoja de propiedades y esperar "burbujear" ese valor a través de la herencia, porque lo que se hereda es en realidad la fórmula "$ (IntDir)", cuyo valor eventualmente se resolverá a nivel de proyecto / configuración / archivo).
• Una hoja de propiedades ya cargada se ignora (parece evitar que la misma hoja de propiedades tenga agregadas dos macros de usuario)
• Tanto "/" como "/" parecen funcionar en rutas de hoja de propiedades (y en la mayoría de los lugares donde VS espera una ruta).
• Se supone que una ruta de hoja de propiedades que comienza con "/" (después de que se hayan resuelto las macros) está en "./", donde ''.'' es la ubicación de la hoja de llamada / proyecto). Lo mismo si la ruta no comienza con "./", "../" o "unidad: /" (no sé acerca de UNC).