Site web publier des échecs dus chemin d'accès du fichier est trop long

Je suis en train de publier un projet de Site web d'un fournisseur qui a ridiculement longs chemins pour certains de ses fichiers. Lors de la publication, l'erreur est:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Lorsque je publie, Visual Studio 2012 Update 3 est la tentative d'écriture dans un répertoire temporaire, et le préfixe est assez longue:

 C:\Users\cuser\AppData\Local\Temp\WebSitePublish\MidasCMS400v9-1580334405\obj\Debug\Package\PackageTmp\

J'ai pensé que je pourrais être en mesure de rediriger les VS vers un autre répertoire temporaire à c:\tem en suivant ce DONC réponse: Temp chemin d'accès trop long lors de la publication d'un projet de site web

J'ai créer mon profil de publication, et dès que je l'ouvre, il y a un message d'erreur indiquant que WebPublishMethod n'est pas un élément de PropertyGroup. Peu importe, j'ai mis à jour le fichier de sorte qu'il ressemble à ceci:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <publishUrl>C:\Sites\MidasPublish</publishUrl>
    <DeleteExistingFiles>False</DeleteExistingFiles>
    <AspnetCompileMergeIntermediateOutputPath>c:\tem\</AspnetCompileMergeIntermediateOutputPath>
  </PropertyGroup>
</Project>

Quand j'essaie de le publier, j'ai l'modale de la boîte de pop-up intitulé "Modification de Fichier Détecté", avec le message "Le projet YourWebsite a été modifié en dehors de l'environnement", et il me demande si je veux recharger. Dans ma liste d'erreurs, j'obtiens toujours l'erreur sur le chemin étant trop long, car il n'est pas en essayant d'utiliser le c:\tem répertoire que j'ai identifié.

J'ai besoin de mettre ce truc sur un serveur, je suis pour la solution qui me permet de publier ce machin. Je ne sais pas beaucoup sur le projet de Site web modèle, de sorte s'il vous plaît laissez-moi savoir si il ya une meilleure façon.

Salut, avez-vous toute solution du problème ci-dessus, je suis également confronté au même problème.
Je crains que non, j'ai juste enlever une partie de la plus profonde des dossiers pour contourner le problème - ne pas l'idéal!
Ouais. J'ai moi aussi fini par faire manuel xcopy au lieu d'utiliser bouton droit de la souris cliquez sur>>option publier.
Jetez un oeil à cette réponse. Il a résolu le problème pour moi.stackoverflow.com/a/12656574/179673
J'ai eu le même message d'erreur. Mon problème était lié à des noms de fichiers longs dans le App_Data solution de sous-dossiers. De renommer les fichiers avec des noms courts résolu le problème pour moi.

InformationsquelleAutor Mister Epic | 2013-10-16

45

De http://forums.asp.net/t/1944241.aspx?Website+publier+défaut+grâce+à+fichier+chemin+être+trop+long

Ajoutez la ligne suivante à défaut PropertyGroup de projet web fichier.
```
<IntermediateOutputPath>..\Temp</IntermediateOutputPath>
```
Vous pouvez probablement faire le chemin d'accès ci-dessus C:\temp ou........ \Temp (pour parvenir au plus près de la racine du lecteur que possible.

Dans mon cas, il n'y avait pas .csproj ou .vbproj (site du projet), mais il y avait un site web.publishproj fichier que vous avertit de ne pas le modifier, mais je n'ai de toute façon, et il a fait le tour.
- j'étais à la recherche à partir de là que j'ai besoin d'ajouter la balise. Une fois que j'ai recheckd la réponse, là. J'ai donc juste fait comme audacieux pour le remarquer en lisant la première fois, Merci pour la mise à jour.
- Donc, je suis récemment tombé sur quelques nouvelles, des informations utiles liées à cela: Dans le Site web\App_Data\PublishProfiles, vous pouvez modifier la .pubxml fichier créé lorsque vous avez de la publication des profils. Dans ce fichier, vous pouvez créer une balise <aspnetcompilemergeintermediateoutputpath>. C'est un bon (et permanente) de l'itinéraire de l'édition du site web généré.publishproj fichier.
- Nous courons MSBuild à partir de Jenkins. J'ai simplement ajouter la ligne suivante à la ligne de commande pour le faire fonctionner: /p:IntermediateOutputPath=c:\temp\ (note le slash est nécessaire).
- Je sais que c'est un vieux thread. Mais cette <IntermediateOutputPath>..\Temp\</IntermediateOutputPath> ne fonctionne pas avec PrecompileBeforePublish>True</PrecompileBeforePublish> . Toute aide serait appréciée.
- Par la façon dont il fonctionne également si vous ajoutez cette ligne dans votre .csproj.fichier de l'utilisateur! Donc pas besoin de modifier principal .fichier csproj et le désordre avec les autres programmeurs dans votre équipe et TFS (si vous l'utilisez).
InformationsquelleAutor Jason Beck
3

Grâce à Stelvio, à partir de http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation , il existe une solution :

Bien, j'ai trouvé une solution de contournement qui PERMETTENT de travailler avec chemin d'accès avec plus de 260 caractères.

Avertissement: j'ai essayé ce truc uniquement sur Windows 8 x64 et Visual Studio 2013

Donc, pour le faire fonctionner, je viens de créer une jonction au dossier avec la commande mklink:

Suppose que c'est le chemin d'origine: d:\very\very\long\path\to\solution\folder vous pouvez obtenir un lien court comme d:\short_path_to_solution_folder juste jaunching cette commande à partir d'un shell dos en tant qu'administrateur:
mklink /J d:\short_path_to_solution_folder d:\very\very\long\path\to\solution\folder

modifier la source et le chemin de destination pour vous besoins

En Ce Qui Concerne Meilleur!
Stelvio

à partir de ce lien :
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation

InformationsquelleAutor Alexei Bondarev
2

Tout en déplaçant le projet plus proche de la racine de fichier ne fonctionne pas. J'ai trouvé un lien vers une solution qui a fonctionné pour moi. Le site a également fait un excellent travail lors de la discussion de la question ainsi que les détails derrière sa solution.

Sayed Hashimi solution à long problème de chemin d'accès

EDIT:

Pour Résumer le lien fourni:

Vous pouvez mettre à jour votre profil de publication de fichiers, qui est utilisé par MSBuild, afin d'inclure une remplacer la règle qui permettra de raccourcir le chemin de votre sortie lors de la publication sur le web de déployer un package (fichier Zip).

Par exemple, disons publication à l'aide du profil par défaut créé par Visual Studio, nous obtenons les chemins d'accès suivants dans le fichier zip:
```
archive.xml
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\bin
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\bin\WebApplication1.dll
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\index.html
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\Web.config
parameters.xml
systemInfo.xml
```
L'astuce consiste à remplacer tout le chemin défini après le Contenu avec un chemin plus court. Dans cet exemple, remplacez le chemin d'accès avec "site web" dans la PackagePath élément.

Peut modifier l'une de l'édition de fichier de profil (.pubxml) et ajouter le suivi des lignes vers la fin du fichier, juste avant l'élément du Projet est terminée.
```
<PropertyGroup>
  <PackagePath Condition=" '$(PackagePath)'=='' ">website</PackagePath>
  <EnableAddReplaceToUpdatePacakgePath Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='' ">true</EnableAddReplaceToUpdatePacakgePath>
    <PackageDependsOn>
    $(PackageDependsOn);
    AddReplaceRuleForAppPath;
    </PackageDependsOn>
</PropertyGroup>
<Target Name="AddReplaceRuleForAppPath" Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='true' ">
  <PropertyGroup>
    <_PkgPathFull>$([System.IO.Path]::GetFullPath($(WPPAllFilesInSingleFolder)))</_PkgPathFull>
  </PropertyGroup>

  
  <EscapeTextForRegularExpressions Text="$(_PkgPathFull)">
    <Output TaskParameter="Result" PropertyName="_PkgPathRegex" />
  </EscapeTextForRegularExpressions>

  
  <ItemGroup>
    <MsDeployReplaceRules Include="replaceFullPath">
      <Match>$(_PkgPathRegex)</Match>
      <Replace>$(PackagePath)</Replace>
    </MsDeployReplaceRules>
  </ItemGroup>
</Target>
```
Maintenant, le profil de publication des chemins devrait ressembler à quelque chose comme ce qui suit:
```
archive.xml
Content\website
Content\website\bin
Content\website\bin\WebApplication1.dll
Content\website\index.html
Content\website\Web.config
parameters.xml
systemInfo.xml
```
- Alors que ce lien peut répondre à la question, il est préférable d'inclure les parties essentielles de la réponse ici et de fournir le lien de référence. Lien-ne répond peut devenir non valide si la page liée changements.
- J'aime cette réponse, que le problème que j'ai également observé que pas nécessairement directement liés à la production intermédiaire, mais plutôt le long chemin d'accès inclus dans le package zippé fichier. Avec cela, vous n'avez pas à modifier l'intermédiaire de la sortie de l'intégralité de votre projet, et ne touchent que la publication de la web déployer le package.
InformationsquelleAutor Kram_Koorbse
0

La réponse de Jason Beck a travaillé pour moi, avec un petit changement. Pour éviter l'erreur "Le IntermediateOutputPath doit se terminer par une barre oblique." utiliser le "\" à la fin de la trajectoire:
..\Temp\

Votre "CONFIG_PUBLISH_FILE.pubxml" devrait ressembler à ceci (Les "..." omet d'autres fichier de configuration que vous pouvez avoir):

...

...
..\Temp\
...

InformationsquelleAutor mqueirozcorreia
0

Au moment de la publication du projet, le compilateur visual studio vérifie la taille des fichiers qui font partie du projet.

J'ai donc cherché longtemps dans les noms de fichiers.
J'ai trouvé et renommé les fichiers.

A fait un Travail parfaitement

InformationsquelleAutor Rodrigo Cury
-4

Cette erreur vient du fait que, de longue nom de chemin d'accès....U suffit de couper votre dossier à partir de l'actuel emplacement pour disque D ou F du lecteur. supposons que votre projet nom du dossier est "myproject", et vous devriez vous couper de ce dossier et collez le disque D de F en voiture,que votre nom de chemin d'accès sera D:\myproject ou F:\myproject. Ensuite, vous le publier à nouveau......Il va travailler...

InformationsquelleAutor Aby C Paul

Vous devez vous connecter pour publier un commentaire.