MSBuild DeployOnBuild = true ne pas publier

J’ai une application Web Visual Studio 2010 MVC2 que je construis via la ligne de commande en utilisant Hudson. J’aimerais que Hudson publie une sortie Web, j’ai donc ajouté les balises DeployOnBuild = true et CreatePackageOnPublish = True à ma ligne de commande.

Ma commande est la suivante:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /target:Clean,Build /property:Configuration=Debug;DeployOnBuild=True;CreatePackageOnPublish=True; [my project name.csproj] 

L’exécution de cette commande sur mon ordinateur de développement (Windows 7) permet de publier une sortie Web dans \obj\Debug\Package\PackageTmp\ . Mais l’exécuter sur le serveur Hudson (WS 2008) se comstack avec succès, mais ne le publie pas. Même commande, même version de MSBuild, même code source.

J’ai essayé la cible /t:Publish , ce qui me donne une réponse Skipping Unpublishable Project, comme je l’ai vu sur plusieurs articles d’autres personnes.

J’ai également essayé d’append les DeployOnBuild=True et CreatePackageOnPublish=True à mon fichier de projet, sans modification.

Des reflections sur la raison pour laquelle ce n’est pas la publication? Est-ce que j’utilise ces tags de manière incorrecte? Je suis sûr qu’il y a quelque chose ici que je ne vois pas.

    En supposant que Visual Studio 2010 ne soit pas installé sur votre serveur hudson, il se peut que vous n’ayez pas le fichier de “cibles” de publication. Après beaucoup de coups de tête, j’ai finalement résolu ce problème.

    Pendant un moment, j’ai su que je devais copier le répertoire

    C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications

    de ma machine locale avec VS2010 à mon serveur afin de construire le projet. Mais pour que le projet soit aussi publié, je devais également copier le répertoire

    C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web

    Remarque: Dans mon cas, je suis en train de valider ces dossiers sur mon contrôle de source et de modifier la valeur de dans mon fichier csproj pour pointer vers ces dossiers extraits (il y a donc une étape de moins lors de la préparation d’un serveur). Ce n’est pas nécessaire pour le faire fonctionner, mais vous voudrez peut-être envisager cela après avoir résolu votre problème.

    UPDATE: Donc, après avoir fait ce qui précède, le build s’est plaint qu’il ne pouvait pas trouver “Microsoft.Web.Deployment.dll”. Pour résoudre ce problème, je devais installer Microsoft Web Deploy v2.0 sur le serveur même si je publie uniquement sur le système de fichiers . Je suppose que je peux voir la logique dans ceci.

    MISE À JOUR: J’ai découvert que l’installation de “Visual Studio 2010 Shell (Integrated)” via IIS Web Platform Installer installera les cibles de génération requirejses. Cela semble être un bon compromis entre ne pas avoir toute l’application Visual Studio installée sur votre serveur et ne pas copier manuellement des dossiers apparemment arbitraires sur votre serveur depuis votre machine de développement.

    Il semble que les conditions pour exécuter la cible de publication ne soient pas satisfaites.

    1) Vous pouvez avoir différents chemins de publication

    2) La condition pour exécuter la cible de publication est fausse

    Pour vérifier que les deux appellent votre commande avec flag / v: diag . Recherchez par cible “Publier” et essayez de comprendre ce qui se passe réellement. Ça va ressembler

     Target "ExecuteT4Templates: (TargetId:144)" in file "D:\App\App.csproj" from project "D:\App\App.csproj": Skipping target "ExecuteT4Templates" because all output files are up-to-date with respect to the input files. Input files: D:\App\App.exe\\App_Config\Configuration.tt;D:\App\App.exe\\App_Config\Debug.App.tt;obj\\Debug.t4lastbuild Output files: D:\App\App.exe\\App.config Done building target "ExecuteT4Templates" in project "App.csproj".: (TargetId:144) 

    A été en cours d’exécution avec VS2012 – a fini par installer des outils de développement Web sur le serveur de génération et que le problème a été résolu.

    Suite à la réponse de Brian Hinchey, j’ai constaté que je devais également append mon appel par lots msbuild avec le paramètre supplémentaire VisualStudioVersion afin que la version et le chemin corrects de l’agent de génération (TeamCity dans mon cas) vers Microsoft.WebApplication.targets soient appelé. Sans ce paramètre, l’étape Web de déploiement et de publication n’était pas terminée et mon lot terminé avec un code 0 renvoyé rendant l’parsing très difficile – même avec l’indicateur / verbosity ajouté pour «déboguer» la génération. Ce point est fait par SAYED IBRAHIM HASHIMI sur son site: http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx

    Le scénario pour mon cas était que la compatibilité de Visual Studio était activée sur mon projet Web MVC pour que je puisse ouvrir le projet dans VS2010 ou 2012 (comme le note Sayed dans le lien ci-dessus) – donc je suis localement dans VS2012 alors que l’agent de génération TeamCity a des cibles de création et de déploiement Web pour VS 2010.