S'il vous plaît aller facile je suis nouveau à Msbuild et MsbuildTasks!
Comment puis-je définir une propriété qui représente un chemin de fichier relatif vers un fichier cibles que je veux importer? J'ai besoin de références relatives afin qu'il fonctionnera sur toutes les machines de dev. Mais la cible d'importation tente d'utiliser le chemin de fichier relatif interne, qui ne fonctionnera pas car il est réévalué par rapport à la cible importée!
efficacement j'essaie de contourner le comportement documenté d'importé Projets:
Tous les chemins relatifs dans importés Les projets sont interprétés par rapport à le répertoire du projet importé. Par conséquent, si un fichier de projet est importé dans plusieurs fichiers de projet dans différents endroits, le parent Chemins dans le fichier de projet importé sera interprété différemment pour chaque projet importé.
6 Réponses :
Il y avait une question similaire à est-il possible d'utiliser MsBuild Extension Pack sans installation? . Cette question était de savoir comment faire la même chose avec le EXTENSION MSBUILD , qui sont tous deux similaires dans cet aspect . Pour le pack d'extension, vous devez déclarer la propriété ExtensionTaskspath , et pour les tâches communautaires, vous devez déclarer une propriété similaire nommée MsBuildCommunitoSksLib . Donc, dans votre cas, il devrait ressembler à:
Mais ce sont des chemins de fichiers absolus non? Ou suis-je misérable? Je dois y référer avec un chemin de fichier relatif, ou du moins pour pouvoir convertir le chemin de fichier relatif au moment de l'exécution.
La plupart des outils nécessitent un chemin complet pour fonctionner correctement. J'ai mis en place quelques variables dans un .proj que je suis incué dans tous mes fichiers de «travail» .Proj. Ces variables contiennent la partie fixe des chemins pour diverses choses. Dans un groupe de propriétés:
Vous devriez être capable de créer un chemin complet de chemin relatif. Vous pouvez utiliser des propriétés comme MsbuildProjectDirectory.
"
Ceci semble être une réponse:
http: / /social.msdn.microsoft.com/forums/en-us/msbuild/thread/feb782e3-72ae-4476-9011-617796f217b6
Mais cela (si je le comprends correctement) semble être une solution ridicule. Pour faire fonctionner les chemins, je dois modifier les références de projet importées? Que se passerait-il si je voulais faire référence au projet importé du troisième projet dans un autre dossier?!?
OK, j'ai trouvé la réponse. Nous devons essentiellement définir la propriété MsbuildCommunityTaskspa comme chemin relatif de retour au répertoire contenant l'original.
Par exemple, étant donné une structure de dossier comme celle-ci: p>
p>
<Import Project="..\..\Tools\MSBuildCommunityTasks\MsBuild.Community.Tasks.Targets"/>
@sayed Ibrahim Hashimi
Talkin à propos de Msbuild4
Juste déclarer le fichier msbuildcommunittaskslib ne suffit pas si vous vérifiez le fichier msbuild.community.tasks.targets Les propriétés sont déclarées comme suit donc si vous ne faites que si vous ne surviendrez pas Encore une fois, découvrez-vous dans le fichier msbuild.community.tasks.tasks.tachsets comme il n'est pas conditionnel
Donc, vous devez également remplacer MsbuildCommunityTasksPath afin que sa place ne soit pas définie à partir de MsbuildextensionsPath, mais de votre chemin personnalisé.
Corrète moi si je me trompe
Je suis un noob à Msbuild si je suis assez honnête, mais je viens de résoudre mon propre problème que j'avais avec ça. Je tournais l'une des cibles en son propre projet et cela ne trouvait pas les chemins des chemins communautaires Msbuild. Si vous regardez votre projet d'origine, vous pouvez trouver quelque chose comme celui-ci copier ce code dans votre nouveau projet et cela devrait fonctionner.
Cela ne peut pas fonctionner. Vos variables ne sont même pas échappées avec $ (). Exemple:
Je voulais juste ajouter, car je ne peux pas commenter (représentant), que pour faire un chemin vers votre projet particulier, vous pouvez utiliser $ (solutionDir) sur votre groupe de propriétés, comme:
$ (solutiondir) \ My Code \ Community \ Msbuild \ CommunityTasks \
De cette façon, il n'est pas lié à un lecteur spécifique et peut être basé sur l'emplacement du projet par rapport à votre structure de répertoire de solutions.
Aussi merci pour la réponse ci-dessus, cela m'a aidé dans mon projet avec l'addition ci-dessus.
Y a-t-il une raison particulière pour laquelle vous ne mettez pas la part de MsbuildCommunityTask Side côte à côte avec Msbuild à% PROGDIR% \ MSBUILD \ MSBUILDCOMMUNITYTASKS \? Le chemin pourrait alors être relatif à Msbuild (comme suggéré par MSbCt People):