J'ai une solution que j'essaie de vous mettre à construire sur TFS. Je souhaite mettre à jour les versions de tous les fichiers appropriés et je suis resté coincé à essayer de le faire. Il y a beaucoup de liens sur la façon de le faire, mais aucun d'entre eux ne fonctionne pour moi, en raison d'un petit problème ... Portée.
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3074]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 7/6/2009 3:54:10 PM.
Project "D:\src\test.proj" on node 0 (default targets).
CSFiles: 'application\Properties\AssemblyInfo.cs'
DesktopBuild:
CSFiles: ''
Done Building Project "D:\src\test.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.04
Lorsque j'exécute "C: \ Windows \ Microsoft.net \ Framework \ v3.5 \ msbuild.exe test.proj" Dans le dossier de la solution ... Je reçois la sortie suivante: P>
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<Target Name="DesktopBuild">
<CallTarget Targets="GetFiles" />
<Message Text="CSFiles: '@(CSFiles)'" />
</Target>
<Target Name="GetFiles">
<ItemGroup>
<CSFiles Include="**\AssemblyInfo.cs" />
</ItemGroup>
<Message Text="CSFiles: '@(CSFiles)'" />
</Target>
</Project>
4 Réponses :
Avez-vous essayé d'utiliser Dependsontarget plutôt que CallTarget? Il se peut que CallTarget provoque le problème de la portée.
Ok, cela semble me donner d'autres informations. Je peux changer la portée du groupe d'éléments en utilisant DEPENDONON, mais cela ne semble pas cohérent. Il semble que les frères et sœurs des cibles ont appelé Dependson ont accès au groupe de choses, mais le parent ne le fait jamais. Si étrange. Y a-t-il des documents n'importe où montrant les règles de portée? Je ne pouvais pas les trouver et je suppose que maintenant je dois réécrire mes fichiers en utilisant des dépendances complexes plutôt que des appels. C'est tellement fou.
Je n'ai vu aucun. Avez-vous essayé simplement de déplacer le groupe d'objets en dehors des objectifs entièrement? Y a-t-il une raison pour laquelle vous ne voulez pas faire ça?
Ou initialiser-le à l'extérieur pour vider (hack avec inclus = "*. Wontexist")
Je dois faire le groupe d'éléments dans une cible, car elle est dans une construction TFS, je me suis nédée de tirer les fichiers après-garde ... (J'utilise Beforecompile, mais quoi que ce soit) et Thomas, j'ai essayé cela, ne fonctionne pas. Il ajoute à la variable globale de l'instance localement scopée. Que vous utilisiez un fichier existant ou non.
#blessyou (et l'affiche de la question initiale)
Nous faisons quelque chose de similaire dans notre construction. Nous passons la version comme un paramètre de ligne de commande.
Dans notre TFSBUILD.PROJ Nous définissons la version sur 0.0.0.0 si aucune version n'a été fournie: alors nous faisons Ceci:
Juste fyi, existe ne fait pas ce que ce code semble s'attendre à ce que ce soit. Existe des vérifications pour voir si le fichier nommé existe, non pas si la variable nommée existe. Vous voulez probablement la condition = "'$ (version)' == ''" à la place. Voir msdn.microsoft.com/en-us/library/7szfhaft.aspx
Ce type technophile est intelligent. :-) Ce qu'il a dit. La manière standard du DOC est d'entourer de citations simples et de mettre de nombreuses personnes autour de ...
Merci Chris. :) Nous sommes en train de faire un tas de travail sur notre environnement CI, c'est donc tout très frais dans mon esprit. ;)
Bonne techno attrape. Il apparaît que les valeurs de ligne de commande passées ne sont pas capables d'être remplacées dans des groupes de propriété.
@David Je ne suis pas sûr de ce que vous voulez dire. Vous pouvez faire ce que vous avez initialement destiné (il est par défaut s'il n'est pas transmis sur la ligne de commande) comme:
Le commentateur précédent a été correct, vous devez modifier cela pour utiliser DepwewnArgets au lieu d'utiliser la tâche CallTarget. Ce que vous voyez est un Bug PAS UNE SCOPING INSSUE. WAY pour éviter Ce bogue est d'utiliser Dependweontargets (qui est une approche bien meilleure quand même).
Sayed Ibrahim Hashimi
Est-ce vraiment un bug? L'explication offerte ici est également convaincante et est corroborée par le fait qu'il s'agit toujours de la manière dont cela fonctionne, plusieurs années plus tard.
C'est un bug, s'il vous plaît voir blogs.msdn.com/ B / MSBUILD / Archive / 2006/01/03 / 508629.aspx
Comme indiqué, vous devez utiliser DepwenSontargets. J'ai fait des recherches sur la portée Msbuild, vous pouvez trouver mes résultats sur mon blog: http://blog.qetza.net/2009/10/23/scope-of-properties-an-item-in-an-msbuild-script/
La chose est qu'il semble y avoir une portée globale pour le projet et une portée locale de la cible. Lors de la saisie de la cible, la portée globale est copiée et lors de la sortie de la cible, la portée locale est fusionnée. Ainsi, un callTarget n'obtiendra pas les valeurs de portée locales modifiées, mais les Dépendsontargets ne seront pas sorties depuis la première cible avant la saisie de la deuxième cible.
Essayez-vous de construire le fichier test.proj? Je ne suis pas sûr de comprendre pourquoi vous spécifiez AssemblyInfo.cs par rapport à la construction du fichier de projet.
J'ai construit le fichier test.Proj comme un exemple minimal montrant mon problème. En réalité, j'essaie de construire mon fichier de solution multiple dans TFS. Ceci est juste pour illustrer le comportement de cadrage que je constate dans des groupes de choses et des objectifs.
J'aimerais pouvoir uppoter toutes les personnes qui essaient d'aider, mais apparemment je suis trop «Newb». Je voulais juste laisser notez une note que j'apprécie le temps que tout le monde a passé ici à regarder et à y penser.