J'ai une application Web Visual Studio 2010 MVC2 que je crée 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:
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 ma machine de développement (Windows 7) publie avec succès une sortie Web vers \obj\Debug\Package\PackageTmp\
. Mais l'exécuter sur le serveur Hudson (WS 2008) se compile avec succès, mais il ne publie pas. Même commande, même version de MSBuild, même code source.
J'ai essayé le /t:Publish
target, ce qui me donne une réponse Skipping Unpublishable Project, comme je l'ai vu sur plusieurs publications d'autres personnes.
J'ai essayé d'ajouter le DeployOnBuild=True
et CreatePackageOnPublish=True
balises également dans mon fichier de projet, et aucun changement.
Avez-vous des idées sur la raison pour laquelle ce n'est pas publié? Suis-je en train d'utiliser ces balises de manière incorrecte? Je suis sûr qu'il y a quelque chose ici que je ne vois tout simplement pas.
En supposant que vous n'avez pas pas Visual Studio 2010 installé sur votre serveur hudson, il se peut que le fichier "cibles" de publication soit manquant. Après beaucoup de coups de tête à bureau, j'ai finalement résolu cela.
Depuis longtemps, je sais 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 d'obtenir le projet à construire . Mais pour que le projet publie également , je devais également copier sur le répertoire
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
Remarque: dans mon cas, je valide ces dossiers sur mon contrôle de code source et je modifie le <MSBuildExtensionsPath32>
valeur 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 considérer cela après avoir résolu votre problème.
MISE À JOUR: 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. sur le serveur même si je publie uniquement sur le système de fichiers . Je suppose que je peux voir la logique dans tout cela.
MISE À JOUR: J'ai découvert que l'installation de "Visual Studio 2010 Shell (Integrated)" via le programme d'installation de la plateforme Web IIS installera les cibles de génération requises. Cela semble être un bon compromis entre ne pas avoir l'intégralité de Visual Application Studio installée sur votre serveur et ne copiant pas manuellement les dossiers apparemment arbitraires sur votre serveur depuis votre machine de développement.
Il semble que les conditions d'exécution de la cible de publication ne soient pas remplies.
1) Vous pouvez avoir différents chemins de publication
2) La condition pour exécuter la cible de publication est fausse
Pour vérifier les deux, appelez votre commande avec flag / v: diag. Recherchez par ciblez "Publier" et essayez de comprendre ce qui se passe réellement. Cela ressemblera à
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)
Était en cours d'exécution avec VS2012 - a fini par installer des outils de développement Web sur le serveur de build et cela l'a corrigé.
Suite à la réponse de Brian Hinchey, j'ai trouvé que je devais également ajouter mon appel de lot msbuild avec le paramètre supplémentaire VisualStudioVersion afin que la version et le chemin corrects sur l'agent de construction (TeamCity dans mon cas) vers Microsoft.WebApplication.targets soient appelé. Sans ce paramètre, l'étape de déploiement et de publication Web n'a pas été terminée et mon lot s'est terminé avec succès avec un code 0 renvoyé, ce qui rend l'analyse 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 j'avais la compatibilité Visual Studio activée sur mon projet Web MVC afin que je puisse ouvrir le projet dans VS2010 ou 2012 (comme le dit Sayed dans le lien ci-dessus) - donc je dev'ing localement dans VS2012 tandis que l'agent de génération TeamCity possède les cibles de génération et de déploiement Web VS 2010.