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

- Conf’SharePoint : 10 bonnes raisons pour ne pas la rater par Le petit blog de Pierre / Pierre's little blog le 05-14-2013, 02:24

- [Event] Soirée de lancement Agile .NET France à Lyon par Blog Agile/ALM de Vincent THAVONEKHAM le 05-13-2013, 01:29

- .NET / Debug : inspection de la mémoire d'applications .NET (dump ou processus live) : première livraison d'une librairie .NET par Microsoft par CoqBlog le 05-11-2013, 22:21

- SharePoint : Incompatibilité avec Internet Explorer 10 (IE10) par Blog Technique de Romelard Fabrice le 05-08-2013, 16:29

- AutoSPInstaller pour SharePoint 2013 maintenant disponible en “RTM” par Julien Chable le 05-06-2013, 23:30

- [TFS2010] A la recherche du Shelveset perdu par Blog de Jérémy Jeanson le 05-03-2013, 21:46

- .NET / Debug post-mortem : obtenir le fichier mscordacwks.dll correspondant à un dump quand on n'a plus d'accès direct à ce fichier par CoqBlog le 04-28-2013, 19:57

- [W8] Afficher un graphe par CPU dans le gestionnaire des tâches par Blog de Jérémy Jeanson le 04-28-2013, 17:48

- [WCF] Limiter proprement l’accès à vos ressources serveur par Blog de Jérémy Jeanson le 04-26-2013, 22:59

- Event : Je serai speaker à la Conf’SharePoint par Blog Technique de Romelard Fabrice le 04-26-2013, 12:00