Dans l'événement de construction de mon projet de démonstration, (un projet de bibliothèque de classes) , pour copier le résultat de construction .dll dans un dossier spécifique, (créé automatiquement s'il n'existe pas) , j'ai ajouté la ligne de commande suivante dans la section de ligne de commande Événement post-construction :
set targetfile=%~1 set targetdir=%~2 echo %targetfile% echo %targetdir% xcopy /Y %targetfile% %targetdir%
Cela fonctionne parfaitement. p>
Ensuite, j'ai essayé de remplacer cette ligne de commande par un appel à un nouveau fichier batch appelé CopyPackage.bat situé dans $ (SolutionDir). Le contenu du fichier de commandes est exactement la ligne de commande ci-dessus:
call $(SolutionDir)CopyPackage.bat
Ensuite, je reconstruis le projet et j'obtiens l'erreur suivante:
Code de gravité Description État de suppression de la ligne du fichier de projet Erreur La commande "call C: \ TestProjects \ DemoApp \ CopyPackage.bat" s'est terminée avec le code 4. DemoApp
Est-ce que je rate quelque chose?
La solution après avoir obtenu quelques conseils de vous tous:
Dans ligne de commande d'événement post-build J'ai mis: (voir les paramètres)
$ (SolutionDir) CopyPackage.bat "$ (TargetDir) $ (TargetFileName)" "$ (SolutionDir) DemoApp \ bin \ $ (ConfigurationName) \ Packages \"
Dans le fichier batch CopyPackage.bat :
xcopy /Y "$(TargetDir)$(TargetFileName)" "$(SolutionDir)DemoApp\bin\$(ConfigurationName)\Packages\"
3 Réponses :
call est une commande interne de cmd.exe vous devez utiliser
cmd.exe /c "$(SolutionDir)CopyPackage.bat"
instead.
Modifier :
Le contenu du fichier batch correspond exactement à la ligne de commande ci-dessus
Les variables VS ne seront pas correctement résolues dans le fichier .bat. Vous devez les transmettre en tant que paramètres au fichier de commandes.
ou simplement "$ (SolutionDir) CopyPackage.bat"
Je pense que la vraie réponse se trouve sur la dernière ligne de votre réponse. Le script de la question échoue probablement car il utilise une variable msbuild dans le fichier bat
@Baruch Je crois que l'appel explicite de cmd.exe supprimera toute ambiguïté.
Passer le paramètre au fichier de commandes est la bonne manière pour ma démonstration. Pour un fonctionnement dans le monde réel, il est préférable d'utiliser le script du moteur de construction réel pour gérer tous les remplacements, etc.
@MagB Bien sûr, il y a plus d'une solution pour une copie de fichier post-construction, la mienne concernait votre cas spécifique.
Pas besoin d'utiliser call , vous pouvez simplement appeler le script batch directement.
Je dois vous avertir, car les cibles post-build n'ont aucun moyen de connaître les entrées et les sorties de la tâche, il devra toujours exécuter le script, même si rien n'a changé.
Au lieu de cela, si vous convertissez cela en une cible msbuild et que vous implémentez correctement la signalisation d'entrée / sortie, vous gagnerez un beaucoup de temps en étant capable de tirer parti des fonctionnalités de construction incrémentielle de MsBuild.
Par exemple:
<Target Name="CopyOutputs"
Inputs="@(BuiltAssemblies)"
Outputs="@(BuiltAssemblies -> '$(OutputPath)%(Filename)%(Extension)')">
<Copy
SourceFiles="@(BuiltAssemblies)"
DestinationFolder="$(OutputPath)"/>
</Target>
Plus d'informations sur les constructions incrémentielles et la signalisation d'entrée / sortie peut être trouvée:
+1 pour la suggestion MsBuild, je l'essayerai plus tard également. Mais MS insiste pour utiliser 'call' pour s'assurer que toutes les commandes suivantes sont exécutées: docs.microsoft.com/en-us/visualstudio/ide/...
Changer le chemin de votre CopyPackage.bat en chemin absolu peut aider à résoudre ce problème.
Des propriétés comme celles-ci: $ (TargetDir), $ (SolutionDir) sont reconnues par l'outil msbuild.exe car elles font partie des propriétés msbuild et sont définies ou importées dans l'environnement actuel.
Lorsque vous utilisez xcopy / Y "$ (TargetDir) $ (TargetFileName)" "$ (SolutionDir) DemoApp \ bin \ $ (ConfigurationName) \ Packages \" dans un événement post-build, le L'outil msbuild peut les reconnaître, donc pour la première fois, il réussit.
Cependant, pour la deuxième fois. Le moteur msbuild peut reconnaître les propriétés dans l'événement post-build, donc il appelle le .bat avec succès. Mais comme le .bat ne peut pas reconnaître la propriété Msbuild (ces propriétés ne peuvent être reconnues que par MSbuild.exe, pas par .bat ou cmd.exe), la compilation échouera pour ne pas trouver le chemin.
Le remplacement des variables par des chemins codés en dur est la pire solution possible.
@montonero Oui, mais ce que vous voulez savoir est "Est-ce que je rate quelque chose?", et je veux juste vous dire que le problème provient du fichier .bat ne peut pas reconnaître les propriétés msbuild. Si vous voulez un moyen simple de le faire, il pourrait être préférable de conserver la commande d'origine dans post-build-event.
Votre solution est une (très) mauvaise pratique. Peu importe à quel point c'est facile. Un simple transfert du dossier du projet le cassera.