47 votes

Échec du déploiement de MSBuild après la mise à niveau vers .NET 4.5

Nous avons récemment changé notre rapport à 2010 et .NET 4 application de VS 2012 et .NET 4.5. Nous avons un script de compilation 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 que l'autre est Windows 7 avec VS 2010 et VS 2012 (installé récemment).

Lors de l'exécution du script de build de Windows 8 boîte de construire script fonctionne bien et déploie l'application sur le serveur test. Mais lors du déploiement de l'application à partir de Windows 7 case j'obtiens l'erreur suivante:

"C:\Achinth\Build\Work\build\qa1sb.proj" (DeployAll cible) (1) ->"C:\Achinth\Build\Work\App\App.csproj" (ResolveReferences;MsDeployPublish cible) (2) ->(MSDeployPublish cible) -> C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.La publication.cibles(3847,5): erreur : le site Web de tâches de déploiement a échoué.((8/19/2012 6:23:41 PM) Une erreur s'est produite lors de la demande a été traitée sur l'ordinateur distant.) [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.La publication.cibles(3847,5): erreur : \r [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.La publication.cibles(3847,5): erreur : (8/19/2012 6:23:41 PM) Une erreur s'est produite lors de 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.La publication.cibles(3847,5): erreur : Le pool d'applications que vous essayez d'utiliser est le 'managedRuntimeVersion' propriété a la valeur 'v4.0'. Cette application nécessite des " v4.5'. [C:\Achinth\Build\Work\App\App.csproj]

En regardant l'erreur, il semble que MSBuild est l'aide de VS 2010 cibles au lieu de VS 2012, qui est à l'origine de l'erreur. Depuis Windows 8 boîte n'a pas de VS 2010, c'est à l'aide de VS 2012 cibles correctement.

Certains ont-ils un s'il vous plaît fournir des conseils sur la façon de faire MSBuild pour choisir la bonne version?

58voto

Sayed Ibrahim Hashimi Points 25707

Dans ce cas, vous devrez spécifier la propriété MSBuild VisualStudioVersion=11.0. J'ai juste écrit à ce sujet à l' http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspxj'ai collé ci-dessous pour votre commodité.

L'une des fonctionnalités les plus demandées de Visual Studio 2012 a la capacité d'ouvrir des projets dans les deux VS 2012 ainsi que par rapport à 2010 (nécessite visual studio 2010 SP1). Dans le cas où vous ne l'avez pas entendu, nous ne l'implémentation de la fonctionnalité. Vous demandez peut-être comment nous avons été capables de faire cela et comment cela peut avoir un impact sur vous.

Si vous ouvrez le .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 de VS 2012 il y a quelques modifications apportées à votre fichier de projet pour s'assurer qu'il peut être ouvert dans les deux VS 2010 SP1 et VS 2012. L'un des changements apportés au projet lorsqu'il est chargé pour la première fois dans VS 2012 est d'ajouter ce qui suit pour remplacer cette instruction import.

<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 retiré les codée en dur 10.0, et a plutôt utilisé la propriété VisualStudioVersion. Lors de la construction dans Visual Studio 2012, cette valeur sera toujours 11.0, mais pour VS 2010, il n'existe pas. C'est pourquoi nous avons manqué à 10.0 ci-dessus. Il y a quelques scénarios où la construction de la ligne de commande nécessitera de définir explicitement cette propriété. Avant de nous y rendre laissez-moi vous expliquer comment cette propriété est défini (dans cet ordre)

  1. Si VisualStudioVersion est définie comme une variable d'environnement/global MSBuild propriété, qui est utilisé.
    • C'est de cette manière VS et VS développeur invite de commande, définissez cette valeur
  2. Basé sur la version du format de fichier de l' .la sln fichier (ensemble d'outils utilisé est la sln format de fichier -1)
    • Pour simplifier cette déclaration, l' .la sln fichier construira avec la spécification VisualStudioVersion à la valeur de la version de VS, qui l'a créé .la sln fichier.
  3. Choisissez par défaut
    • 10.0 si VS 2010 est installé
    • Plus de version sous-ensemble d'outils de la version installée

Pour le #2, lorsque vous construisez une .la sln fichier de la valeur de VisualStudioVersion sera -1 du Format de la Version trouvée dans le .la sln fichier. La chose importante à noter ici est que si vous construisez une .la sln fichier il va construire avec la valeur de VisualStudioVersion correspondant à la version de VS, qui l'a créé .la sln fichier. Donc, si vous créez une .la sln fichier dans VS2012 et il est toujours à construire .la sln fichier de la valeur pour VisualStudioVersion sera 11.0. Dans de nombreux cas, si vous construisez .la sln fichier que vous êtes bon.

Si vous êtes à la construction .csproj/.les fichiers vbproj w/o passant par un .la sln fichier? Si vous créez un projet web à partir de la ligne de commande (pas le développeur de l'invite de commandes) alors la valeur de VisualStudioVersion utilisé sera 10.0. C'est un artefact de l'propriétés qui je l'ai montré ci-dessus. Dans ce cas, vous devez passer cela comme une propriété MSBuild. Par exemple

msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0

Dans ce cas, je suis de passage dans la propriété explicitement. Ce sera toujours la priorité sur tout autre mécanisme permettant de déterminer la valeur de VisualStudioVersion. Si vous utilisez la tâche MSBuild dans un script de compilation, vous pouvez spécifier la propriété, soit dans les Propriétés de l'attribut ou de la AdditionalProperties attribut. Voir mon précédent billet sur la différence entre les Propriétés et les AdditionalProperties.

Si vous rencontrez un drôle de comportement lors de la construction, de la publication, et vous remarquez que le mal .objectifs de fichiers sont importés, alors vous pouvez avoir besoin de spécifier cette propriété.

41voto

Abhishikt N. Jain Points 331

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. "

Cela a fonctionné pour moi.

2voto

sevzas Points 124

J'ai observé que lorsque j'utilise VS2012 Publier le site Web de Déployer le Package, il génère un .fichier zip. À l'intérieur de que zip il y a un fichier appelé archive.xml qui contient un createApp de la balise avec l'attribut " managedRuntimeVersion="v4.0"' . Lorsque j'utilise msdeploy.exe pour le synchroniser à une instance de iis, il fonctionne.

Cependant, lorsque j'utilise msbuild.exe pour créer un package web .fichier zip, il contient un archive.xml qui a des " managedRuntimeVersion="v4.5"'. En essayant de déployer le package web d'IIS à l'aide msdeploy.exe résultats dans les ERROR_APPPOOL_VERSION_MISMATCH erreur.

Comme Sayed Ibrahim Hashimi a expliqué, ajoutant "/p:VisualStudioVersion=11.0" à mon msbuild.exe ligne de commande de manière efficace des forces managedRuntimeVersion="v4.0"' dans le archive.xml résultant de l'offre web, de sorte qu'il résout le problème.

2voto

misterduck Points 56

Pour tous ceux qui trouvaient cette page cherchant pourquoi msdeploy / webdeploy montrait 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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X