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 dans 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 tout ce que je vois dans la sortie de la construction est le suivant:
4> Projet de construction terminé "{Projet} .csproj".
4> Suppression de fichiers existants ...
4> Dossier de publication/...
4> ========= Build: 3 réussis, 0 échoués, 1 à jour, 0 ignorés ==========
========== Publication: 1 réussie, 0 échouée, 0 ignorée ===========
Même s'il est indiqué que la publication a réussi, il n'y a pas de fichiers dans le répertoire cible pour la publication.
Je l'ai vu dans plusieurs projets et parfois, il semble que les configurations Solution/Plate-forme soient à l'origine de ce problème, mais je n'ai pas été en mesure de déterminer la cause exacte de ce problème.
Est-ce que quelqu'un d'autre a vu cela ou a une idée sur la façon de le faire fonctionner correctement?
METTRE À JOUR:
J'ai peut-être trouvé une solution de contournement pour cela. Je viens juste que cela se reproduise et je déconnais les paramètres de publication. Une fois que j'ai changé la configuration sélectionnée sous l'onglet Paramètres, elle a été remplacée par une autre configuration, puis celle que je voulais utiliser pour tous mes fichiers a recommencé à être publiée. Espérons que cela fonctionne sur d'autres projets dans le futur.
MISE À JOUR 2:
J'ai posté un bogue sur Microsoft Connect et un développeur de l'équipe VS Web Developer nous a répondu. Il a déclaré qu'ils avaient résolu ce problème dans leurs versions internes et qu'ils publieraient bientôt une mise à jour de l'outil de publication afin de résoudre 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 quelques mois et a résolu le problème en s'assurant que les configurations de construction de ma solution correspondent à celles 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 for Web. J'ai fait exactement ce que l'affiche originale suggérait et cela réglait mon problème.
Voici le fil qui me mène à 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 la suivante:
Publié par Microsoft le 13/06/2012 à 12h00 PM Bonjour Andrew,
C'était un bug dans la façon dont nous gérons la configuration de la solution par rapport au configuration du projet. Nous avons supposé à tort qu’ils seraient le identique (par exemple, la version | x86 de Solution aurait pour chaque projet la valeur La version | x86 également), ce qui nous a amené à utiliser la mauvaise version propriétés pour la publication de fichiers.
La solution consiste à configurer et à générer la solution correspondance de configuration. Ce problème sera résolu dans la prochaine version de Visual Studio 2012.
Merci, - Jimmy Lewis SDET, équipe de développeurs Visual Web
Même problème. La solution de contournement consistait à modifier les paramètres de publication de Release à Debug. Republiez, puis revenez à Libérer ...
Pour aller un peu plus loin. Vous avez deux fichiers créés lorsque vous créez un profil de publication.
NewProfile.pubxmlNewProfile.pubxml.user
Lorsque vous ouvrez un projet contenant ces fichiers dans le dossier PublishProfile à partir d'un contrôle source, il ne contient que le fichier .pubxml et non le fichier .publxml.user; il crée donc le fichier .publxml.user à la volée lors de l'ouverture du projet . 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 ressemblant à ceci:
<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 noeud <PropertyGroup> et le placez dans le fichier .pubxml.user, vos PublishProfiles recommenceront à fonctionner.
Une solution simple consiste à supprimer votre profil de publication et à en créer un nouveau.
lorsque vous cliquez avec le bouton 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 de passer de 2010 à 2012
J'ai eu la même erreur et je change le réglage de release en debug et le problème est résolu ..
J'ai eu ce même problème cependant aucune des réponses dans ce fil n'a fonctionné pour moi. Mon problème était qu'il y a 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 ya quelque temps et que j’ai pensé documenter, c’est 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 les 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 changé dans Visual Studio.
Sélectionnez le (s) fichier (s) non copié (s). Dans Properties, assurez-vous que Build Action est défini sur Content.
Si cela ne fonctionne pas, vous pouvez essayer ce qui suit.
Dans le menu Project, sélectionnez Package/Publish Web et notez ce menu déroulant:
Essayez de changer ceci en Tous les fichiers dans ce dossier de projet.
J'ai essayé toutes ces solutions mais c'est celle qui fonctionne à chaque fois.
Nous modifions simplement la "méthode de publication:" de "système de fichiers" en "Web Deploy", par exemple, et le remettions immédiatement à "système de fichiers".
Cela est dû au fait que .pubxml.user contient les informations requises pour la publication et que ce fichier n'est pas (et ne devrait pas) être inclus dans le contrôle de source. Pour résoudre 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 ceux-ci dans votre fichier .pubxml et vous devriez être prêt à partir.
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 du nombre généré par publishxml ne produit aucune différence et ne semble donc pas du tout liée au profil.
La solution de contournement mentionnée par OP pour changer les problèmes de build semble être la seule solution fiable pour le moment.
Ce qui suit a fonctionné pour moi:
Changez simplement de Release> Debug> Release (ou inversement) puis publiez.
Pas besoin de supprimer, éditer, publier tout ce dont vous n'avez pas besoin.
Mon problème était dans la mauvaise configuration du fichier myproject.csproj. Le fichier '_address-step1 -stock.cshtml' n'a pas été copié lors de la publication. 'Aucun' a été remplacé par 'Contenu', maintenant ça va . 
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 ajouter/supprimer) qui, je crois, avait été récemment mise à jour en v1. 0,30810,0. Cela a résolu le problème.
Ici nous avons eu le même problème.
Nous modifions simplement la "méthode de publication:" de "système de fichiers" en "Web Deploy", par exemple, et le remettions immédiatement à "système de fichiers".
Même problème avec VS 2012 Pro avec une cible de publication sur disque. Le projet utilisait pour publier correctement, mais a commencé à résoudre ce problème où il n'a pas pu copier les fichiers dans le dossier de destination.
La solution consistait à éditer le profil de publication, à changer le mode de Release (Any CPU) à déboguer puis à revenir à Release (Any CPU). Cela entraîne la réécriture du fichier PublishProfiles\nomprojet.pubxml.user (comme décrit ci-dessus). On dirait qu'elle a ajouté les éléments LastUsedBuild, LastUsedPlatform et TimeStampOfAssociatedLegacyPublishXmlFile sous le nœud propertygroup. Une fois la publication terminée, il ajoute un autre groupe d'éléments avec des fichiers individuels et des temps de publication.
A eu le même problème récemment dans VS 2013 pour un projet MVC dans lequel j'ai importé Umbraco CMS. Je ne pouvais pas publier. La réponse ci-dessus m'a aidé, même s'il me fallait un peu de temps pour comprendre ce que je devais réellement faire avec VS. Il avait besoin de recherches, par exemple. sur les blogs MS pour le savoir. J'essaie de le dire simplement:
- Choisissez une configuration dans la barre d’outils VS, par exemple. Release et Any CPU. Exécutez le projet.
- Cliquez ensuite avec le bouton droit de la souris sur l'explorateur de solutions sur la solution en question, puis 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, Libérer et N'importe quel processeur) est choisie, comme avant la dernière exécution du projet.
- De plus, dans mon cas, il s’agissait du dossier nécessaire de supprimer le dossier OBJ, car les paramètres de ma dernière tentative de publication infructueuse se sont bloqués, bien que j’ai redémarré VS et supprimé tous les profils de publication.
J'ai trouvé que je pouvais contourner ce problème en modifiant l'emplacement cible d'obj/[release | stage | ..] en un nouveau chemin situé complètement en dehors des dossiers de la solution, par exemple c:\deployment. Il semble que VS 2012 était en train de devenir confus et d'abandonner quelque part pendant le processus de publication.
Mat
Cette action a été un succès pour moi:
Supprimez les profils de publication dans "Propriétés> PublishProfiles> xxxx.pubxml" et redéfinissez-les.
Pour ce que ça vaut, j’ai finalement renoncé à me battre avec Web Deploy pour le faire faire ce que je voulais (copier des fichiers déployables et rien d’autre), j’ai donc écrit le script dans PowerShell et je suis vraiment content du résultat. C'est beaucoup plus rapide que tout ce que j'ai essayé avec MSBuild/Web Publish, probablement parce que ces méthodes faisaient toujours des choses dont je n'avais pas besoin.
Voici le Gist ( 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 de CI (TeamCity), mais il pourrait également être facilement associé à un événement post-construction.
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 en version pour un projet qui avait été manqué dans le passé. La prochaine fois que j'ai tenté de me déployer, j'ai eu ces symptômes, où la publication échoue tout doucement - 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 consistait à supprimer le profil de publication, à fermer Visual Studio pour le forcer à enregistrer la suppression, à le rouvrir et à recréer le profil de publication à partir de zéro. Une fois que j'ai fait cela, je pouvais publier à nouveau correctement.
Win8 VS2012, ordinateur portable de merde.
Vérifiez dans votre projet actuel si vous avez créé une copie arrière 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 va confondre le compilateur !!!
CodeFile = "Consolidated.aspx.vb" Inherits = "Consolidated
J'ai rencontré ce problème avec les fichiers Service Reference générés par Visual Studio et dont la longueur totale du chemin était trop longue.
Réduisez-les en générant à nouveau 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 situé dans le fichier Reference.cs) pour éviter les erreurs de compilation.
http://myservice doit être remplacé par l'URL du noeud final du service.
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 va maintenant publier correctement. Cela se produit souvent à la suite d'un profil de publication contrôlé par une source provenant d'un autre ordinateur créé dans une version plus récente de Visual Studio.
J'ai le même problème. Aucune des solutions ci-dessus n'a fonctionné pour moi.
J'ai donc exclu les fichiers dont la copie a échoué lors de la publication.
J'ai publié le site plusieurs fois. Mais un jour, lorsque j'ai modifié un fichier aspx et que j'ai ensuite essayé de publier le site Web, le dossier publié était vide.
Sur ma solution de contournement, j'ai trouvé une solution.
L'assistant de publication reflète les erreurs éventuelles lors de la publication mais ne copie aucun fichier dans le dossier de destination.
Pour trouver 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.
Maintenant, lorsque vous essayez de publier, il vous donnera le nom du fichier qui contient des erreurs.
Il suffit de rectifier l'erreur dans le dossier du site Web d'origine et d'essayer de publier, cela fonctionnera comme auparavant.
Aucune des solutions ci-dessus n'a fonctionné pour moi.
J'ai toutefois remarqué que sur nos cinq projets ASP.NET MVC de notre solution principale, quatre d'entre eux placent le package de déploiement à la bonne place, tandis qu'un autre le laissait sous obj\Debug.
J'ai comparé les projets et trouvé une différence. La solution était de changer cela :
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
pour ça :
<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 apporté cette modification, les cinq projets ont placé leurs packages de déploiement au bon endroit.
(Désolé pour les longues lignes, mais je ne pouvais pas trouver un meilleur moyen de les condenser.)
J'ai finalement trouvé la réponse par moi-même. Toutes les solutions ci-dessus ne fonctionnent pas pour moi.
Ce que j’ai fait, c’est que je déplace le projet pour que c change le dossier du projet en quelque chose de plus court et qu’il soit publié.
la raison pour laquelle cela a échoué de mon côté est que j'avais un très long projet nom/hiérarchie.
C:\Utilisateurs\utilisateur\Bureau\Système de gestion de la conformité\ComplianceIssueManagementSystem\ComplianceIssueManagementSystem
J'avais pensé à cela parce que parfois, quand j'extrais 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 Publier. et ça le fait!
j'espère que ça va vous aider les gars.
Dans Visual Studio 2012, le passage d'une version à une autre pose toujours des problèmes.
Nous avons ajouté un événement de pré-génération pour supprimer le dossier obj: del /s /f /q $(ProjectDir)\obj et le problème de publication a été résolu. Le nettoyage fonctionne parfois, mais pas toujours.