Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

Team Build : error MSB3554 - The fully qualified file name must be less than 260 characters

Lorsque l’on utilise Team Build pour compiler nos projets, il se peut que l’on tombe sur le problème suivant :

error MSB3554: Cannot write to the output file XXX. 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.

Il ne s’agit en aucun cas d’un bug de TFS ou de Visual Studio, mais d’une limitation de windows. En effet, l’interface de windows ne permet pas d’avoir un fichier dont le nom complet a une taille supérieur à 260 caractères (File Names, Paths, and Namespaces (MSDN)).
Par défaut, lorsque l’on configure un serveur de build, le workspace utilisé est C:\Documents and Settings\tfsBuild\Local Settings\Temp\ProjectName\, si l’on a un projet avec des namespaces conséquent, on arrive rapidement à cette taille limite.

La solution est donc de changer le chemin du workspace par défaut. Pour cela dans Team Explorer, faites un click droit sur le noeud “Builds” puis “Manage Build Agents …

image  

image

Dans le champ “Working Directory”  au lieu de $(Temp)\$(BuildDefinitionPath) utilisez C:\Build\$(BuildDefinitionId). Ainsi, le workspace sera c:\Build\123 au lieu de C:\Documents and Settings\tfsBuild\Local Settings\Temp\ProjectName\ soit une cinquantaine de caractères de gagnés.

Pour information, voici la description des 2 variables utilisées.

  • $(BuildDefinitionId) - a 32-bit identifier for a definition that uniquely identifies it for the Team Foundation Server
  • $(BuildDefinitionPath) - a path of the form <Team Project>\<Definition Name>

Vous pouvez également utiliser n’importe quelle variable d’environnement Windows.

Posted: mardi 29 septembre 2009 00:00 par cyril
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

brunews a dit :

RECTIF:

Windows et son NTFS codent la longueur des FullPathName sur INT16 SIGNES donc 32000 et des brouettes.

L'erreur citée ici ne relève donc du fait que c'est encore une dotnetterie à la c...

Quand donc MS se décidera enfin (je n'y crois plus) à refaire coder ses logiciels par des professionnels ???

# septembre 29, 2009 12:09

christian a dit :

Hello Bruno

D'accord avec toi pour l'API mais je cite (j'ai mis le lien vers la msdn FR):

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters.

http://msdn.microsoft.com/fr-fr/library/aa365247(VS.85).aspx

Il est vrai un peu plus ils indiquent que :

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters.

Je pense que le dévelopeur c'est arrêté sur le 1er paragraphe :o(

# septembre 29, 2009 19:18

cyril a dit :

Oui, j'ai seulement parcouru l'article MSDN cité :)

D'experience (je viens de retester) :

- L'explorateur Windows ne peut pas créer un fichier avec une taille aussi grande

- .net ne permet d'écrire ce genre de fichier

De plus, ce n'était pas le sujet de ce post donc j'ai pas creusé.

Mais suite à ce que je viens de lire, quelqu'un sait pourquoi explorer et .net se limite à 260 char ? Pourquoi il faut utiliser \\?\c:\

<LongPathName> pour accéder à des fichiers aux noms longs ?

# septembre 29, 2009 23:07

cyril a dit :

Merci Coq pour ces infos, ces articles expliquent comment utiliser les "long path". Par contre, je n'ai pas trouvé pourquoi la limite de 260 char existent. C'est un héritage de FAT ? quel élément a été limitant ?

# septembre 30, 2009 00:45

coq a dit :

Ha oui pour la raison de cette limitation sur la plateforme en elle même je ne sais pas du tout, je parlais juste de celle expliquant le non-support de \\?\ de base par .NET

# septembre 30, 2009 22:01

pe.dautreppe a dit :

Hello Cyril,

c'est marrant, je viens d'avoir le même type d'erreur mais dans un contexte différent.

Ici j'utilisais PostSharp pour faire de l'injection de code. Ce qu'il se passe est qu'il va décompiler la DLL et extraire toutes les ressources dans un folder.

Pour peu que le répertoire soit long (comme dans ton exemple) mais qu'en plus l'identifiant de la ressource soit long (VS prend comme identifiant le "full path" du fichier (namespaces + nom du fichier), on va facilement dépasser les 260.

Dans mon cas j'ai contourné le problème en changeant l'identifiant des ressources. Le fichier ne change pas d'emplacement ni de nom, mais c'est le nom de la ressource dans le code IL qui change. Ceci est possible directement dans le csproj en indiquant le tag

<LogicalName> comme enfant de <EmbeddedResource>.

A l'occasion je bloggerais un truc là dessus.

# décembre 3, 2009 12:24
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

- SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01