3 votes

Utilisation de la paraffine avec le TFS

J'ai une solution qui comporte un certain nombre de projets Wix que j'aimerais utiliser. Paraffine pour maintenir la liste des fichiers inclus.

D'après ce que j'ai compris, vous dirigez normalement Paraffin vers les différents dossiers de poubelle pour collecter tous les fichiers.

Lorsque TFS construit une solution, il remplace la propriété OutDir msbuild, ce qui a pour conséquence que toutes les sorties de construction vont dans un répertoire Binaries commun, plutôt que dans le dossier bin de chaque projet.

Alors comment les gens utilisent-ils la paraffine dans ce scénario ?

2voto

Davidson Corry Points 158

Je n'ai pas utilisé paraffine en années. La dernière version peut faire ce dont vous avez besoin, mais laissez-moi vous donner quelques idées supplémentaires que vous pourrez peut-être utiliser avec ou sans paraffine .

L'un des inconvénients de paraffine , chaleur y suif est qu'ils récoltent binaires qui doivent donc exister, se trouver dans les dossiers appropriés, etc. Une alternative est de récolter à partir du .sln lui-même et le fichier .proj qu'il référence -- la solution est vraisemblablement la liste définitive de ce que les binaires sont et ne sont pas dans le produit|package. Vous pourriez être en mesure de générer automatiquement des fragments pour chaque binaire au moment de la construction, sans avoir à maintenir ces fragments dans le contrôle de source et sans avoir à construire réellement les binaires.

Examinez l'intégration de MSBuild dans WiX 3.6+, en particulier la fonction objectifs de récolte . Si cela ne fonctionne pas pour vous, essayez ceci :

Une approche que nous avons adoptée sur un projet récent a permis de contourner chaleur entièrement. Nous avons écrit une activité de flux de travail pour scanner le .sln et son .proj et générer un WiX Fragment pour chaque binaire directement -- ce ne sont que des documents XML. Un UUID version 3 a été généré sur la base du nom du binaire, du dossier cible et de la version de construction (crédit Derek Cicerone pour cette idée) de sorte que ComponentID sont cohérentes d'une version à l'autre, mais sont automatiquement mises à jour lorsqu'elles sont branchées sur une nouvelle version.

Certains binaires de la solution (par exemple, les gabarits de test) que nous ne voulions pas mettre dans le paquet d'installation, nous avons donc injecté une nouvelle propriété MSBuild dans le paquet d'installation. .proj pour marquer "installable" (ou non). Vous pourriez injecter une propriété pour spécifier le répertoire cible -- dans notre cas, tous les binaires étaient supposée pour aller dans le même dossier, donc nous n'en avons pas eu besoin. Vous pouvez même créer une page de propriétés de projet Visual Studio personnalisée pour cela, si vous voulez être fantaisiste.

L'un des avantages de ce système est que les développeurs d'applications de l'équipe peuvent simplement ajouter un nouveau binaire à la solution, ou en supprimer un existant, et le paquet d'installation synchronise automatiquement ce qui se trouve dans la solution. .msi lors de la prochaine construction. Cela a évité bien des tracas à l'installateur (votre serviteur) !

Vous pourriez combiner ces deux approches : analyser la solution pour savoir quels binaires elle construit, puis utiliser ces informations pour cibler les éléments suivants paraffine o chaleur dans les dossiers appropriés pour le moissonnage.

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