Échec du déploiement de MSBuild après la mise à niveau vers .NET 4.5
Nous avons récemment mis à niveau notre application VS 2010 et .NET 4 vers VS 2012 et .NET 4.5. Nous avons un script de construction pour déployer l'application sur le serveur de test. Nous avons deux boîtes - l'une est Windows 8 avec VS 2012 (nouvelle installation) et l'autre est Windows 7 avec VS 2010 et VS 2012 (nouvellement installé).
Lors de l'exécution du script de construction à partir de Windows 8, le script de construction de la boîte fonctionne correctement et déploie l'application sur le serveur de test. Mais lors du déploiement de l'application à partir de Windows 7, j'obtiens l'erreur suivante:
"C:\Achinth\Build\Work\build\qa1sb.proj" (cible DeployAll) (1) -> "C:\Achinth\Build\Work\App\App.csproj" (ResolveReferences; MsDeployPublish target) (2) -> (cible MSDeployPublish) -> C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3847,5): erreur: la tâche de déploiement Web a échoué. ( (8/19/2012 6:23:41 PM) Une erreur s'est produite lors du traitement de la demande sur l'ordinateur distant.) [C:\Achinth\Build\Work\App\App.csproj] C:\Program Files (x86 )\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3847,5): erreur:\r [C:\Achinth\Build\Work\App\App.csproj] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3847,5): erreur: (8/19/2012 6:23:41 PM) Une erreur s'est produite lorsque la demande a été traitée sur l'ordinateur distant.\r [C:\Achinth\Build\Work\App\App.csproj] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft. Web.Publishing.targets (3847,5): erreur: le pool d'applications t Ce que vous essayez d'utiliser a la propriété "managedRuntimeVersion" définie sur "v4.0". Cette application nécessite "v4.5". [C:\Achinth\Build\Work\App\App.csproj]
En regardant l'erreur, il semble que MSBuild utilise des cibles VS 2010 au lieu de VS 2012, ce qui provoque l'erreur. Étant donné que la boîte de Windows 8 n'a pas VS 2010, elle utilise correctement les cibles VS 2012.
Quelqu'un peut-il s'il vous plaît fournir des conseils sur la façon de faire MSBuild pour choisir la bonne version?
Dans ce cas, vous devrez spécifier la propriété MSBuild VisualStudioVersion = 11.0. Je viens de bloguer à ce sujet sur http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx , je l'ai collé ci-dessous également pour votre commodité.
L'une des fonctionnalités les plus demandées de Visual Studio 2012 était la possibilité d'ouvrir des projets dans VS 2012 ainsi que dans VS 2010 (nécessite VS 2010 SP1). Au cas où vous n’auriez pas entendu que nous avons mis en œuvre cette fonctionnalité. Vous vous demandez peut-être comment nous avons pu le faire et comment cela peut vous affecter.
Si vous ouvrez le fichier .csproj/.vbproj pour un projet Web créé dans VS2010, vous verrez l'instruction d'importation suivante.
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\
v10.0\WebApplications\Microsoft.WebApplication.targets" />
Lorsque vous ouvrez ce projet dans VS 2012, quelques modifications sont apportées à votre fichier de projet pour vous assurer qu'il peut être ouvert à la fois dans VS 2010 SP1 et VS 2012. L'une des modifications apportées au projet lors de son premier chargement dans VS 2012 consiste à ajouter ce qui suit pour remplacer cette instruction d'importation.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">
$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Nous avons supprimé la version 10.0 codée en dur et utilisé à la place la propriété VisualStudioVersion. Lors de la génération dans Visual Studio 2012, cette valeur sera toujours 11,0, mais pour VS 2010, elle n'existe pas. C'est pourquoi nous l'avons défini par défaut sur 10.0 ci-dessus. Il existe certains scénarios dans lesquels la construction à partir de la ligne de commande nécessite de définir explicitement cette propriété. Avant d'y arriver, laissez-moi vous expliquer comment cette propriété est définie (dans cet ordre)
- Si VisualStudioVersion est défini comme une variable d'environnement/propriété globale MSBuild, cela est utilisé.
- Voici comment VS et l'invite de commande du développeur VS définissent cette valeur
- Basé sur la version au format de fichier du fichier .sln (le jeu d'outils utilisé est le format de fichier sln –1)
- Pour simplifier cette instruction, le fichier .sln sera construit en spécifiant VisualStudioVersion à la valeur de la version de VS qui a créé le fichier .sln.
- Choisissez la valeur par défaut
- 10.0 si VS 2010 est installé
- Version du sous-ensemble d'outils la plus haute version installée
Pour # 2 lorsque vous créez un fichier .sln, la valeur de VisualStudioVersion sera –1 de la version de format trouvée dans le fichier .sln. La chose importante à noter ici est que si vous créez un fichier .sln, il sera construit avec la valeur de VisualStudioVersion correspondant à la version de VS qui a créé le fichier .sln. Donc, si vous créez un fichier .sln dans VS2012 et que vous créez toujours ce fichier .sln, la valeur de VisualStudioVersion sera 11.0. Dans de nombreux cas, si vous créez le fichier .sln, vous êtes bon.
Si vous créez des fichiers .csproj/.vbproj sans passer par un fichier .sln? Si vous générez un projet Web à partir de la ligne de commande (et non de l'invite du développeur), la valeur de VisualStudioVersion utilisée sera 10.0. C'est un artefact des propriétés que j'ai montré ci-dessus. Dans ce cas, vous devez le transmettre en tant que propriété MSBuild. Par exemple
msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0
Dans ce cas, je transmets explicitement la propriété. Cela remplacera toujours tout autre mécanisme pour déterminer la valeur de VisualStudioVersion. Si vous utilisez la tâche MSBuild dans un script de génération, vous pouvez spécifier la propriété dans l'attribut Properties ou l'attribut AdditionalProperties. Voir mon précédent article de blog sur la différence entre les propriétés et les propriétés supplémentaires.
Si vous rencontrez un comportement amusant lors de la génération/publication et que vous remarquez que les mauvais fichiers .targets sont importés, vous devrez peut-être spécifier cette propriété.
de ce lien .
"Ouvrez votre fichier de projet Web * .csproj ou * .vbproj dans un éditeur de texte et ajoutez la ligne suivante.
<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>
J'ai ajouté la ligne juste avant la ligne
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
et il se déploie sans erreur. "
Ça a marché pour moi.
J'ai observé que lorsque j'utilise la fonction VS2012 Publish Web Deploy Package, elle génère un fichier .Zip. A l'intérieur de ce Zip se trouve un fichier appelé archive.xml qui contient une balise createApp avec l'attribut 'managedRuntimeVersion = "v4.0"'. Lorsque j'utilise msdeploy.exe pour le synchroniser avec une instance iis, cela fonctionne.
Cependant, lorsque j'utilise msbuild.exe pour créer un fichier .Zip de package Web, il contient un archive.xml qui a 'managedRuntimeVersion = "v4.5"'. La tentative de déploiement de ce package Web sur IIS à l'aide de msdeploy.exe entraîne l'erreur ERROR_APPPOOL_VERSION_MISMATCH.
Comme Sayed Ibrahim Hashimi l'a expliqué ici, l'ajout de "/p:VisualStudioVersion=11.0" à ma ligne de commande msbuild.exe force effectivement 'managedRuntimeVersion = "v4.0"' dans le fichier archive.xml du package Web résultant afin de résoudre le problème.
Pour tous ceux qui ont trouvé cette page en cherchant pourquoi msdeploy/webdeploy affiche une erreur similaire, j'ai trouvé que c'était la solution.
Pour résoudre le problème, ajoutez simplement la propriété DeployManagedRuntimeVersion dans votre projet VS:
<targetframeworkversion>v4.5</TargetFrameworkVersion></code>
<DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>
À partir d'ici: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html
Dans mon cas, WebDeploy n'a pas été installé sur le serveur de build. Il a donc lancé une erreur similaire. J'ai installé WebDeploy et j'étais en or.
http://www.Microsoft.com/en-ca/download/confirmation.aspx?id=252