Pregunta

He estado tratando de hacer que una tarea en mis compilaciones TFS sea más genérica, y una de las cosas que estoy tratando de hacer es copiar algunos archivos a diferentes directorios, dependiendo de la compilación que use la tarea. Jugué con la idea de usar propiedades, pero no pude pensar en una forma de hacerlo de manera limpia, así que intenté usar metadatos de elementos, ya que he podido hacerlo en otro lugar en el mismo archivo de destino. Estoy trabajando, solo que esta vez, me gustaría usar propiedades.

Esto es lo que quiero hacer:

<ItemGroup>
  <DestinationParent Include="$(DeploymentPath)">
    <DestinationParentPath>$(DeploymentPath)</QuartzParentPath>
  </DestinationParent>
</ItemGroup>

Y más adelante en la compilación, intenté copiar algunos archivos a la carpeta de destino haciendo referencia a los metadatos del elemento:

<Copy SourceFiles="@(FilesToCopy)" DestinationFiles="@(FilesToCopy-&gt;'%(DestinationParentPath)\Destination\%(RecursiveDir)%(Filename)%(Extension)')" ContinueOnError="false" ></Copy>

Desafortunadamente, después de que se ejecuta la compilación, mi BuildLog muestra lo siguiente:

Copying file from "$(BinariesRoot)\%(ConfigurationToBuild.FlavorToBuild)\<File being copied>" to "\Destination\<File being copied>".

% (DestinationParentPath) se había expandido a una cadena vacía, por cualquier razón. El uso de% (DestinationParent.DestinationParentPath) produjo un error que me indica que simplemente debería usar el% (DestinationParentPath). $ (DeploymentPath) se expande a la cadena correcta como se esperaba en otros lugares de la compilación.

Otra fuente de confusión es que el uso de% (ConfigurationToBuild.FlavorToBuild) produjo el valor correcto, es decir, Test, como se puede ver en lo siguiente:

EDITAR: esto se define en el proyecto del nodo raíz, mientras que el Grupo de elementos con DestinationParentPath se define en un nodo de destino. ¿Esto también hace una diferencia?

<ItemGroup>
  <ConfigurationToBuild Include="Test|Any CPU">
    <FlavorToBuild>Test</FlavorToBuild>
    <PlatformToBuild>Any CPU</PlatformToBuild>
  </ConfigurationToBuild>
</ItemGroup>

No parece que el atributo Include sea relevante cuando solo te interesa la cadena en los metadatos del elemento ya que estoy bastante seguro de que " Prueba | Cualquier CPU " no hace referencia a ningún archivo real.

Una vez más, ¿por qué% (DestinationParentPath) se está expandiendo a una cadena vacía?

EDITAR: olvidé mencionar que también intenté codificar la ruta real para DestinationParentPath, pero esto todavía resultó en que% (DestinationParentPath) se expandiera a una cadena vacía.

¿Fue útil?

Solución

  

EDITAR: esto se define en el proyecto del nodo raíz, mientras que el Grupo de elementos con DestinationParentPath se define en un nodo de destino. ¿Esto también hace una diferencia?

Sí, hace una diferencia. La capacidad de definir un ItemGroup dentro de un objetivo es nueva para msbuild 3.5. A pesar de tener un aspecto declarativo, en realidad se ejecuta en tiempo de ejecución como si hubiera llamado las tareas CreateItem / CreateProperty de estilo antiguo. Solo eso conduce a problemas potenciales: debe considerar cuándo se llama (primero) a la tarea que lo contiene. El orden de las operaciones no siempre es obvio para el desnudo ojo . Puede ser conveniente que la tarea en la que utiliza% (DestinationParentPath) dependa de la tarea en la que se creó, incluso si no hay " lógica " dependencia.

Además, existen las antiguas fallas / errores de alcance de msbuild. Propiedades y amp dinámicos; Los elementos no son visibles para " hermano " tareas . Además, artículos actualizados en nested las compilaciones no siempre son burbujeantes .

Echa un vistazo a las soluciones en los enlaces, deberías poder encontrar algo que funcione para ti, incluso si es complicado.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top