Utiliser msbuild pour exécuter un profil de publication de système de fichiers

J’ai ac # .Net 4.0 projet créé avec VS2010 et est maintenant accessible avec VS2012.

J’essaie de publier uniquement les fichiers nécessaires de ce site Web vers un emplacement de destination (C: \ builds \ MyProject [Files])

Ma structure de fichier: ./ProjectRoot/MyProject.csproj ./ProjectRoot/Properties/PublishProfiles/FileSystemDebug.pubxml

Je lance ce qui suit via MSBuild:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild.exe ./ProjectRoot/MyProject.csproj / p: DeployOnBuild = true /p:PublishProfile=./ProjectRoot/Properties/PublishProfiles/FileSystemDebug.pubxml

Voici le xml dans FileSystemDebug.pubxml

  FileSystem Release Any CPU  False C:\builds\MyProject\ True   

Le comportement résultant est:

  • un fichier zip est créé ici: ./ProjectRoot/obj/Debug/Package/MyProject.zip
  • Rien n’est déployé dans C:\builds\MyProject\ WTF
  • Le fichier zip créé est un petit-déjeuner de porcs et rempli de fichiers inutiles à l’application.

Lorsque je lance ce profil de publication via Visual Studio, un dossier est créé dans * C: \ builds \ MyProject * et contient les artefacts exacts que je souhaite.

Comment puis-je obtenir ce résultat simple de msbuild?

FYI: J’ai eu le même problème avec Visual Studio 2015. Après plusieurs heures à essayer, je peux maintenant faire msbuild myproject.csproj /p:DeployOnBuild=true /p:PublishProfile=myprofile .

J’ai dû modifier mon fichier .csproj pour le faire fonctionner. Il contenait une ligne comme celle-ci:

  

J’ai changé cette ligne comme suit:

  

(J’ai changé 10.0 à 14.0, je ne savais pas si c’était nécessaire. Mais j’ai définitivement dû supprimer la partie condition.)

J’ai trouvé la réponse ici: http://www.digitallycreated.net/Blog/59/locally-publishing-a-vs2010-asp.net-web-application-using-msbuild

Visual Studio 2010 est doté de nouvelles fonctionnalités de publication de projets d’application Web qui vous permettent de publier facilement votre projet d’application Web d’un simple clic. Dans les coulisses, la transformation Web.config et la construction du package sont effectuées par un script MSBuild massif importé dans votre fichier de projet (à l’emplacement suivant: C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft .Web.Publishing.targets). Malheureusement, le script est extrêmement compliqué, désordonné et non documenté (autre chose que des commentaires souvent mal orthographiés et pour la plupart inutiles dans le fichier). Un grand organigramme de ce fichier et de la documentation sur la façon de l’intégrer serait bien, mais semble manquer (ou du moins je ne le trouve pas).

Malheureusement, cela signifie que la publication via la ligne de commande est beaucoup plus opaque que nécessaire. J’ai été surpris par le manque de documentation dans ce domaine, car de nos jours, de nombreux magasins utilisent un serveur d’continuous integration et certains font même un déploiement automatisé (que les fonctionnalités de publication de VS2010 pourraient aider). facilement!) aurait été une exigence assez importante pour la fonctionnalité.

Quoi qu’il en soit, après avoir fouillé le fichier Microsoft.Web.Publishing.targets pendant des heures et me suis heurté au mur d’essai et d’erreur, je suis parvenu à comprendre comment Visual Studio semblait effectuer sa magie. et «Construire un package de déploiement». Je vais entrer dans un peu de script MSBuild, donc si vous n’êtes pas familier avec MSBuild, je vous suggère de consulter cette page MSDN.

Publier dans un système de fichiers

La boîte de dialog Publier dans un système de fichiers VS2010 Publish to File System m’a pris du temps à perdre, car je m’attendais à une utilisation judicieuse de MSBuild. Au lieu de cela, VS2010 fait quelque chose de très bizarre: il appelle MSBuild pour effectuer une sorte de demi-déploiement qui prépare les fichiers de l’application Web dans le dossier obj de votre projet, puis il semble faire une copie manuelle de ces fichiers (en dehors de MSBuild) dans votre dossier de publication cible. C’est vraiment un comportement désordonné car MSBuild est conçu pour copier des fichiers autour (et d’autres éléments liés à la construction), il serait donc logique que l’ensemble du processus ne soit qu’une seule cible MSBuild appelée par VS2010, et non une copie manuelle.

Cela signifie que cela via MSBuild sur la ligne de commande n’est pas aussi simple que d’appeler votre fichier de projet avec une cible particulière et de définir certaines propriétés. Vous devrez faire ce que VS2010 aurait dû faire: créez vous-même une cible qui effectue le demi-déploiement, puis copiez les résultats dans le dossier cible. Pour modifier votre fichier de projet, cliquez avec le bouton droit sur le projet dans VS2010 et cliquez sur Décharger le projet, puis cliquez de nouveau avec le bouton droit de la souris et cliquez sur Modifier. Faites défiler la liste jusqu’à trouver l’élément Import qui importe les cibles de l’application Web (Microsoft.WebApplication.targets; ce fichier importe le fichier Microsoft.Web.Publishing.targets mentionné précédemment). Sous cette ligne, nous appendons notre nouvelle cible, appelée PublishToFileSystem:

         

Cette cible dépend de la cible PipelinePreDeployCopyAllFilesToOneFolder, ce que VS2010 appelle avant d’effectuer sa copie manuelle. Certaines recherches dans Microsoft.Web.Publishing.targets montrent que l’appel de cette cible entraîne le placement des fichiers de projet dans le répertoire spécifié par la propriété _PackageTempDir.

La première tâche que nous appelons dans notre cible est la tâche d’erreur, sur laquelle nous avons placé une condition qui garantit que la tâche ne se produit que si la propriété PublishDestination n’a pas été définie. Cela vous empêchera de générer une erreur au cas où vous auriez oublié de spécifier la propriété PublishDestination. Nous appelons ensuite la tâche MakeDir pour créer ce répertoire PublishDestination s’il n’existe pas déjà.

Nous définissons ensuite un élément appelé PublishFiles qui représente tous les fichiers trouvés dans le dossier _PackageTempDir. La tâche de copie est ensuite appelée et copie tous ces fichiers dans le dossier Publish Destination. L’atsortingbut DestinationFiles de l’élément Copy est un peu complexe. il effectue une transformation des éléments et convertit leurs chemins en nouveaux chemins enracinés dans le dossier PublishDestination (consultez les métadonnées d’élément bien connues pour voir ce que ces% () signifient).

Pour appeler cette cible depuis la ligne de commande, nous pouvons simplement exécuter cette commande (en modifiant évidemment le nom du fichier du projet et les propriétés qui vous conviennent):

 msbuild Website.csproj "/p:Platform=AnyCPU;Configuration=Release;PublishDestination=F:\Temp\Publish" /t:PublishToFileSystem 

J’ai toujours eu des problèmes après avoir essayé toutes les réponses ci-dessus (j’utilise Visual Studio 2013). Rien n’a été copié dans le dossier de publication.

Le problème était que si je lance MSBuild avec un projet individuel au lieu d’une solution, je dois mettre un paramètre supplémentaire qui spécifie la version de Visual Studio:

 /p:VisualStudioVersion=12.0 

12.0 est pour VS2013, remplacez par la version que vous utilisez. Une fois que j’ai ajouté ce paramètre, cela a juste fonctionné.

La ligne de commande complète ressemble à ceci:

 MSBuild C:\PathToMyProject\MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=MyPublishProfile /p:VisualStudioVersion=12.0 

Je l’ai trouvé ici:

http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/command-line-deployment

Ils déclarent:

Si vous spécifiez un projet individuel au lieu d’une solution, vous devez append un paramètre qui spécifie la version de Visual Studio.

Il me semble que votre profil de publication n’est pas utilisé et que vous faites un package par défaut. Les cibles Microsoft Web Publish font tout ce que vous faites ci-dessus, elles sélectionnent les cibles correctes basées sur la configuration.

J’ai obtenu que le mien fonctionne sans problème depuis l’étape TeamCity MSBuild, mais j’ai spécifié un chemin explicite vers le profil, il suffit de l’appeler par son nom sans .pubxml (par exemple FileSystemDebug). Il sera trouvé aussi longtemps que dans le dossier standard, qui est le vôtre.

Exemple:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe ./ProjectRoot/MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=FileSystemDebug

Notez que cela a été fait en utilisant les versions Visual Studio 2012 des cibles Microsoft Web Publish, normalement situées dans “C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ Web”. Découvrez le dossier de déploiement pour les cibles de types de déploiement spécifiques utilisées

Vérifiez d’abord la version Visual Studio du PC développeur qui peut publier la solution (projet). comme indiqué est pour VS 2013

  /p:VisualStudioVersion=12.0 

Ajoutez la ligne de commande ci-dessus pour spécifier quel type de version de studio visuel doit générer le projet. Comme dans les réponses précédentes, cela pourrait se produire lorsque nous essayons de publier un seul projet, pas la solution complète.