70 votes

MSBuild passe des paramètres à CallTarget

J'essaie de créer une cible réutilisable dans mon fichier MSBuild afin de pouvoir l'appeler plusieurs fois avec des paramètres différents.

J'ai un squelette comme ça:

 <Target Name="Deploy">
  <!-- Deploy to a different location depending on parameters -->
</Target>

<Target Name="DoDeployments">
  <CallTarget Targets="Deploy">
    <!-- Somehow indicate I want to deploy to dev -->
  </CallTarget>

  <CallTarget Targets="Deploy">
    <!-- Somehow indicate I want to deploy to testing -->
  </CallTarget>
</Target>
 

Mais je ne peux pas comprendre comment permettre aux paramètres d'être passés dans le CallTarget , puis à son tour le Target lui-même.

87voto

ocenteno Points 21

MSBuild cibles ne sont pas conçus pour recevoir des paramètres. Au lieu de cela, ils utilisent les propriétés que vous définissez pour eux.

<PropertyGroup>
  <Environment>myValue</Environment>
</PropertyGroup>
<Target Name="Deploy">
  <!-- Use the Environment property -->
 </Target>

Cependant, un scénario commun est d'invoquer une Cible plusieurs fois avec des paramètres différents (c'est à dire de Déployer plusieurs sites web). Dans ce cas, j'utilise le MSBuild "MSBuild" tâche et envoyer les "paramètres" en tant que Propriétés:

<Target Name="DoDeployments">
    	<MSBuild Projects ="$(MSBuildProjectFullPath)"
    			 Properties ="VDir=MyWebsite;Path=C:\MyWebsite;Environment=$(Environment)"
    			 Targets="Deploy" />

    	<MSBuild Projects ="$(MSBuildProjectFullPath)"
    			 Properties ="VDir=MyWebsite2;Path=C:\MyWebsite2;Environment=$(Environment)"
    			 Targets="Deploy" />
</Target>

$(MSBuildProjectFullPath) est le nom de chemin complet de l'actuel script MSBuild dans le cas où vous ne souhaitez pas envoyer de "Déployer" dans un autre fichier.

Espérons que cette aide!

25voto

George Polevoy Points 2751

Vous pouvez 'foreach' sur un ItemGroup , avec une cible, que vous avez à faire dans declaritive manière. Vous pouvez même avoir des métadonnées supplémentaires dans les objets, comme dans l'exemple de code:

<ItemGroup>
    <What Include="Dev">
        <How>With bugs</How>
    </What>
    <What Include="Test">
        <How>With tests</How>
    </What>
    <What Include="Chicken">
        <How>Deep fried</How>
    </What>
</ItemGroup>

<Target Name="Deploy">
    <Message Text="@(What), %(How)" />
</Target>

À l'aide d'un élément du groupe comme une valeur scalaire @(What) à l'intérieur d'une cible fait le tour, et %(How) fait référence à un élément de métadonnées dans un foreach élément.

C'est une façon naturelle de faire les choses dans msbuild, par exemple, vous pouvez trouver ce modèle partout dans les fichiers de projet généré avec Visual Studio.

1voto

Je penserais très bien à MSBuild dans des termes similaires à un langage de programmation procédurale. Il est conçu pour se comporter différemment.

0voto

Daniel Yankowsky Points 3719

Il pourrait y avoir une meilleure façon de le faire dans MSBuild, mais en Ant, je voudrais utiliser les propriétés globales de transmettre de l'information à partir d'une tâche à l'autre. C'était une bien mauvaise solution, mais je n'ai pas vu de mieux à l'époque. Vous devriez être capable de le faire dans MSBuild, mais gardez à l'esprit que vous aurez besoin d'utiliser l' CreateProperty de la tâche d'attribuer dynamiquement une propriété.

D'autre part, il est assez facile à mettre en œuvre des tâches en C# (ou VB, ou quoi que ce soit). C'est peut-être une meilleure solution pour vous.

0voto

Ming Jia Points 11
    <CreateProperty
        Value="file1">
        <Output
            TaskParameter="Value"
            PropertyName="filename" />
    </CreateProperty>
    <CallTarget Targets="Deploy"/>
    <Message Text="$(filename)"/>
    <CreateProperty
        Value="file2">
        <Output
            TaskParameter="Value"
            PropertyName="filename" />
    </CreateProperty>
    <Message Text="$(filename)"/> 
    <CallTarget Targets="Deploy"/>

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X