Visual Studio 2012 Web Publish ne copie pas les fichiers

J'ai un projet d'application Web dans VS 2012 et lorsque j'utilise l'outil de publication Web, il se construit correctement mais ne copie aucun fichier vers la cible de publication (système de fichiers dans ce cas).

Si je regarde la sortie de la construction, je peux voir que tout est copié correctement dans obj \ Release \ Package \ PackageTmp \ mais alors tout ce que je vois dans la sortie de la construction est le suivant:

4> Projet de construction terminé "{Project} .csproj".
4> Suppression de fichiers existants ...
4> Dossier de publication / ...
4> ========== Build: 3 réussies, 0 échouées, 1 à jour, 0 ignorées ===== =====
========== Publier: 1 réussi, 0 échoué, 0 ignoré ==========

Même s'il indique que la publication a réussi, il n'y a pas de fichiers dans le répertoire cible pour la publication.

J'ai vu cela dans plusieurs projets et il semble parfois que les configurations Solution / Plateforme causent ce problème mais je n'ai pas été en mesure d'identifier une cause exacte à cela.

Quelqu'un d'autre a-t-il vu cela se produire ou a-t-il une idée sur la façon de faire fonctionner cela correctement?

METTRE À JOUR:

J'ai peut-être trouvé une solution pour cela. Je venais juste de recommencer et je jouais avec les paramètres de publication. Une fois que j'ai changé la configuration sélectionnée dans l'onglet Paramètres pour une autre configuration, puis pour revenir à celle que je voulais utiliser, tous mes fichiers ont recommencé à être publiés. Espérons que cela fonctionne sur d'autres projets à l'avenir.

MISE À JOUR 2:

J'ai posté un bug sur Microsoft Connect et entendu un développeur de l'équipe VS Web Developer. Il a déclaré qu'ils avaient corrigé ce problème dans leurs versions internes et publieraient bientôt une mise à jour de l'outil de publication qui résoudrait ce problème.

MISE À JOUR 3:

Cela a été récemment résolu avec Visual Studio 2012 Update 2

Cela peut être dû à des solutions / projets créés avec le RC de vs2012. Cela m'est arrivé il y a des mois et a résolu le problème en m'assurant que les configurations de génération de solution correspondaient aux configurations de mon projet ...

J'ai récemment rencontré le même problème lors de l'ouverture de la même solution créée à l'origine dans vs2012RC avec VS2012 Express pour le Web. J'ai fait exactement ce que l'affiche originale suggérait et cela a résolu mon problème.

Voici le fil qui m'a conduit à la réponse:

connect.microsoft.com/VisualStudio/feedback/details/746321/publish-web-application-fails

La réponse pertinente de la conversation ci-dessus qui m'a aidé était:

Publié par Microsoft le 13/06/2012 à 12:00 PM Bonjour Andrew,

Il s'agissait d'un bug dans la façon dont nous gérons la configuration de la solution par rapport à la configuration du projet. Nous avons supposé à tort qu'ils seraient les mêmes (par exemple, la version | x86 de la solution aurait également pour chaque projet la valeur Release | x86), ce qui nous a amenés à utiliser les mauvaises propriétés de génération pour publier des fichiers.

La solution consiste à faire correspondre la configuration de la solution et la configuration de la construction. Ce problème sera résolu dans la prochaine version de Visual Studio 2012.

Merci, - Jimmy Lewis SDET, équipe de développeur Web visuel

Même problème. La solution de contournement consistait à modifier les paramètres de publication de Release à Debug. Republiez, puis revenez à Release ...

Pour aller un peu plus loin. Vous avez deux fichiers qui sont créés lorsque vous créez un profil de publication.

• NewProfile.pubxml
• NewProfile.pubxml.user

Lorsque vous ouvrez un projet qui contient ces fichiers dans le dossier PublishProfile à partir d'un contrôle source, il n'a que le .pubxmlfichier et non le .publxml.userfichier, il crée donc le .publxml.userfichier à la volée lorsque vous ouvrez le projet. Lorsqu'il crée le nouveau .publxml.userà la volée, le xml ressemble à ceci:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

Lorsque vous créez un nouveau profil, il crée un fichier XML qui ressemble à:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <TimeStampOfAssociatedLegacyPublishXmlFile />
    <EncryptedPassword />
  </PropertyGroup>
</Project>

Si vous prenez le <PropertyGroup>nœud et le placez dans le .pubxml.userfichier, vos profils de publication recommenceront à fonctionner.

Une solution simple consiste à supprimer votre profil de publication et à en créer un nouveau.

lorsque vous faites un clic droit sur votre solution et sélectionnez publier, vous avez un ensemble de profils. supprimez-le et créez-en un nouveau.

cela va le réparer.

J'ai eu ce problème lors du passage de 2010 à 2012

J'ai eu la même erreur et je change le paramètre de la version au débogage et le problème est résolu ..

J'ai eu ce même problème mais aucune des réponses dans ce fil n'a fonctionné pour moi. Mon problème était qu'il existe un répertoire qui contient des fichiers HTML statiques générés dynamiquement (par mon application). Le répertoire entier n'était pas publié.

La solution qui a fonctionné pour moi a été trouvée ici :

Un problème que j'ai eu il y a quelque temps et que je pensais devoir documenter était que certains types de fichiers n'étaient pas téléchargés lorsque j'ai publié mon projet.

Les types de fichiers en question étaient des fichiers .pdf et .rtf.

La raison en est que ces extensions de fichier n'ont pas été reconnues comme nécessitant une publication par Visual Studio. Heureusement, cela peut être modifié dans Visual Studio.

Sélectionnez le ou les fichiers qui ne sont pas copiés. Dans Propriétés, assurez-vous que Build Action est défini sur Content .

Si cela ne fonctionne pas, vous pouvez essayer ce qui suit.

Dans le menu Projet , sélectionnez Package / Publier Web et notez cette liste déroulante:

Essayez de le remplacer par Tous les fichiers de ce dossier de projet.

En effet, le fichier .pubxml.user contient les informations requises pour la publication et ce fichier n'est pas (et ne devrait pas) être inclus dans le contrôle de code source. Pour corriger ce bogue VS, copiez les informations du fichier .pubxml.user dans le fichier .pubxml. Les propriétés pertinentes sont:

<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>

Mettez-les dans votre .pubxml et vous devriez être prêt à partir.

J'ai essayé toutes ces solutions mais c'est celle qui fonctionne à chaque fois.

Nous changeons simplement la "méthode de publication:" de "système de fichiers" en par exemple "Web Deploy", et la changeons immédiatement en "système de fichiers".

J'ai (eu) le même problème pour plusieurs projets. Les seuls touchés semblent être des projets Web. La suppression et la recréation du profil ne résolvent le problème qu'une seule fois. De plus, la comparaison des publications générées par xml ne produit aucune différence, de sorte qu'il ne semble pas du tout lié au profil.

La solution de contournement mentionnée par OP pour modifier les problèmes de construction dans les deux sens semble être la seule solution fiable à l'heure actuelle.

J'ai rencontré le même problème sur VS 2010, après avoir vérifié la sortie de publication, les journaux des événements, allumé et vérifié les journaux de Visual Studio, etc. J'ai ensuite décidé de supprimer la publication Web (via l'ajout / suppression) qui, je crois, avait été récemment mise à jour vers la v1. 0.30810.0. Cela a résolu le problème.

Ici, nous avons eu le même problème.

Nous changeons simplement la "méthode de publication:" de "système de fichiers" en par exemple "Web Deploy", et la changeons immédiatement en "système de fichiers".

Ce qui suit a fonctionné pour moi:

Changez simplement de Release> Debug> Release (ou vice-versa), puis publiez.

Pas besoin de supprimer, modifier, publier tout ce dont vous n'avez pas besoin.

Mon problème était dans une mauvaise configuration du fichier myproject.csproj. Le fichier '_address-step1-stored.cshtml' n'a pas été copié lors de la publication. «Aucun» est devenu «Contenu», maintenant ça va.

Même problème avec VS 2012 Pro avec une cible de publication sur disque. Projet utilisé pour publier correctement mais a commencé à faire ce problème où il n'a pas réussi à copier les fichiers dans le dossier de destination.

La solution était de modifier le profil de publication, de changer le mode de Release (Any CPU) pour déboguer puis de revenir à Release (Any CPU). Cette opération entraîne la réécriture du fichier PublishProfiles \ projname.pubxml.user (comme décrit ci-dessus). Il semble qu'il ait ajouté les éléments LastUsedBuild, LastUsedPlatform et TimeStampOfAssociatedLegacyPublishXmlFile sous le nœud du groupe de propriétés. Une fois la publication terminée, il ajoute un autre ItemGroup avec des fichiers individuels et des heures de publication.

Cette action a réussi pour moi:

Tuez les profils de publication dans "Propriétés> Profils de publication> xxxx.pubxml" et réinitialisez à nouveau.

Pour ce que ça vaut, j'ai finalement renoncé à me battre avec Web Deploy pour qu'il fasse ce que je voulais (copier des fichiers déployables et rien d'autre), donc je l'ai écrit dans PowerShell et je suis vraiment content du résultat. C'est beaucoup plus rapide que tout ce que j'ai essayé via MSBuild / Web Publish, probablement parce que ces méthodes faisaient encore des choses dont je n'avais pas besoin.

Voici l'essentiel ( littéralement ):

function copy-deployable-web-files($proj_path, $deploy_dir) {
  # copy files where Build Action = "Content" 
  $proj_dir = split-path -parent $proj_path
  [xml]$xml = get-content $proj_path
  $xml.Project.ItemGroup | % { $_.Content } | % { $_.Include } | ? { $_ } | % {
    $from = "$proj_dir\$_"
    $to = split-path -parent "$deploy_dir\$_"
    if (!(test-path $to)) { md $to }
    cp $from $to
  }

  # copy everything in bin
  cp "$proj_dir\bin" $deploy_dir -recurse
}

Dans mon cas, j'appelle cela dans un environnement CI (TeamCity), mais cela pourrait également être facilement lié à un événement post-build.

J'ai trouvé que je pouvais contourner ce problème en changeant complètement l'emplacement cible d'obj / [release | stage | ..] en un nouveau chemin en dehors des dossiers de solution, par exemple c: \ deployment. Il semble que VS 2012 devenait confus et abandonnait peut-être quelque part pendant le processus de publication.

Mat

J'ai eu le même problème récemment dans VS 2013 pour un projet MVC dans lequel j'ai importé Umbraco CMS. Je n'ai pas pu publier. La réponse ci-dessus m'a aidé, même si j'avais besoin d'un certain temps pour comprendre ce que je devrais réellement faire dans VS. Il avait besoin de quelques recherches, par exemple sur les blogs de la SEP pour le savoir. J'essaie de le dire simplement:

• Choisissez dans la barre d'outils VS une certaine configuration, par exemple Release et Any CPU. Exécutez le projet.
• Ensuite, faites un clic droit dans l'Explorateur de solutions sur la solution en question, choisissez Publier. Créez un nouveau profil de publication ou utilisez-en un, mais assurez-vous toujours que dans les paramètres la même configuration (par exemple Release et Any CPU) est choisie, comme avant d'exécuter le projet la dernière fois.
• De plus, dans mon cas, il était nécessaire de supprimer le dossier OBJ car ici les paramètres de mes dernières tentatives de publication infructueuses se sont bloqués, bien que j'ai redémarré VS et supprimé tous les profils de publication.

J'ai une application Web avec plusieurs autres projets référencés dans la solution. J'ai déployé avec succès avec une seule configuration de publication plusieurs fois dans le passé. J'ai changé la configuration du projet de Debug à Release pour un projet qui avait été manqué dans le passé. La prochaine fois que j'ai tenté de déployer, j'ai eu ces symptômes, où la publication échoue silencieusement - elle ne fait rien et dit qu'elle a réussi:

1>------ Build started: Project: Project, Configuration: DeployProduction Any CPU ------
1>  
2>Publishing folder /...
========== Build: 1 succeeded, 0 failed, 9 up-to-date, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

Le seul moyen de le récupérer était d'effacer le profil de publication, de fermer Visual Studio pour le forcer à enregistrer la suppression, de le rouvrir et de recréer le profil de publication à partir de zéro. Une fois que je l'ai fait, je pourrais à nouveau publier correctement.

Win8 VS2012, ordinateur portable merdique.

Dans Visual Studio 2012, le basculement entre les versions pose toujours des problèmes.

Nous avons ajouté un événement de pré-génération pour supprimer le objdossier: del /s /f /q $(ProjectDir)\objet cela a résolu le problème de publication. Le nettoyage fonctionne parfois, mais pas toujours.

J'ai finalement trouvé la réponse par moi-même. Toutes les solutions ci-dessus ne fonctionnent pas pour moi.

Ce que j'avais fait, c'est que je déplace le projet pour conduire c changer le dossier du projet en quelque chose de plus court et le boom qu'il publie ..

la raison pour laquelle cela a échoué de mon côté est que j'avais un nom de projet / héritier très long.

C: \ Users \ user \ Desktop \ Compliance Management System \ ComplianceIssueManagementSystem \ ComplianceIssueManagementSystem

J'y avais pensé parce que parfois, quand j'extrayais un fichier rar, il disait que le nom / chemin était trop long. Je pensais que ce serait la même chose que Visual Studio 2012. et c'est le cas!

j'espère que cela vous aidera.

Vérifiez votre projet actuel que si vous avez fait une copie de retour avec le même nom de classe et un nom de page différent (le nom de classe héritera du fichier copié). En fin de compte, cela confondra le compilateur !!!

CodeFile = "Consolidated.aspx.vb" Inherits = "Consolidated

Aucune des solutions ci-dessus n'a fonctionné pour moi.

Mais j'ai remarqué que sur nos cinq projets ASP.NET MVC dans notre solution principale, quatre d'entre eux ont placé le package de déploiement au bon endroit, tandis que l'un l'a laissé sous obj \ Debug.

J'ai comparé les projets et j'ai trouvé un écart. La solution était de changer cela :

<Import
    Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

à ceci :

<Import
  Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets"
  Condition="'$(VSToolsPath)' != ''" />
<Import
  Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
  Condition="false" />

Après avoir effectué ce changement, les cinq projets ont placé leurs packages de déploiement au bon endroit.

(Désolé pour les longues files d'attente, mais je n'ai pas trouvé de meilleur moyen de les condenser.)

J'ai rencontré cela avec la référence de service générée par Visual Studio fichiers de devenant trop longs en termes de longueur de chemin globale.

Les raccourcis en régénérant la référence de service à l'aide de svcutil.exe, en supprimant tous les fichiers de référence de service d'origine.

svcutil peut être appelé comme ceci:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcUtil.exe" /language:CS http://myservice /namespace:*,My.Namespace

My.Namespace doit être remplacé par l'espace de noms existant dans le proxy de service généré (généralement trouvé dans le fichier Reference.cs) pour éviter les erreurs de compilation.

http://myservice doit être remplacé par l'URL du noeud final de service.

J'ai le même problème. Aucune des solutions ci-dessus n'a fonctionné pour moi.

J'ai donc exclu les fichiers qui n'ont pas pu être copiés lors de la publication.

J'avais publié le site Web plusieurs fois. Mais un jour, lorsque j'ai modifié un fichier aspx puis essayé de publier le site Web, cela a abouti à un dossier publié vide.

Sur ma solution de contournement, j'ai trouvé une solution.

1. L'assistant de publication reflétera toute erreur lors de la publication mais ne copiera aucun fichier dans le dossier de destination.

2. Pour découvrir le fichier qui génère l'erreur, copiez simplement le contenu du dossier du site Web dans un nouveau dossier et démarrez Visual Studio avec ce site Web.

3. Maintenant, lorsque vous essayez de le publier, il vous donnera le nom de fichier qui contient des erreurs.

4. Corrigez simplement l'erreur dans le dossier du site Web d'origine et essayez de publier, cela fonctionnera comme auparavant.

Suivez ces étapes pour résoudre:

Build > Publish > Profile > New

Créez un nouveau profil et configurez-le avec les mêmes paramètres que votre profil existant.

Le projet sera désormais publié correctement. Cela se produit souvent à la suite d'un profil de publication contrôlé par la source à partir d'une autre machine qui a été créé dans une version plus récente de Visual Studio.

CORRIGÉ - diverses solutions proposées ne fonctionnaient pas pour moi. Ce qui a fonctionné pour moi avec VS Community 2017, Windows Server 2012 R2 a été de modifier les variables d'environnement TEMP et TMP pour l'utilisateur, puis de redémarrer le système et de déployer à nouveau (le redémarrage de VS ne suffisait pas). Ces variables temporaires sont l'endroit où VS publie la publication temporaire.

Le redémarrage de Visual Studio après avoir changé les variables temporaires n'a pas fait l'affaire, il a fallu redémarrer le système.

Première:

• Construire dans la configuration de la version.
• Dans la page Propriétés du projet->, sélectionnez Tous les fichiers et dossiers sous Package / Publier Web.
• Reconstruire la solution (après la solution Clean).
• publier maintenant.

Lors de la publication, revérifiez ce que vous avez choisi.
cela devrait le faire. Ça l'a fait pour moi! :)

Le plus simple est,

   1. select the file(s) that are not being copied,
   2. Press <F4> to get the properties window
   3. Make the "Build Action" property "compile" or "content" depending on what it is.
   4. Now this particular file will be included!