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.

    Consultant freelance, 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

- Comment mapper une vue SQL sur une collection de complex type? par Matthieu MEZIL le il y a 17 heures et 14 minutes

- SQL Server : Query Notification ou comment être notifié de modifications de données côté application (SqlDependency) par SQL Server vu par Christian Robert le il y a 23 heures et 13 minutes

- [WF4] Un Binding Activity/ActivityDesigner qui passe mal? par Blog de Jérémy Jeanson le 03-19-2010, 13:42

- MyTIC – SharePoint 2010 : déjà un mythe Microsoft ? par Le Blog (Vert) d'Arnaud JUND le 03-19-2010, 08:54

- TechDays 2010 Genève : Retrouvez-moi pour une session sur la Haute disponibilité et le ScaleOut avec SQL Server par SQL Server vu par Christian Robert le 03-18-2010, 15:45

- [MIX10] Keynote deuxième journée – Internet Explorer 9, Html5, Visual Studio 2010, OData par Atteint de JavaScriptite Aiguë [Cyril Durand] le 03-17-2010, 19:40

- Certifications beta .NET 4 par Kévin Gosse le 03-17-2010, 19:33

- [Mix 2010] – Microsoft Translator Technology Preview V2 par RedoBlog - The .NET Gentleman !!! le 03-17-2010, 18:53

- Lancement en Preview de Cyclone lors des TechDays 2010! par Blog de Frédéric Queudret le 03-17-2010, 16:30

- [WP7] Je ne veux pas d’un nouvel iPhone par Le blog de FremyCompany le 03-17-2010, 13:11