Discussion :

[jcd1234]

Bonjour,

Je suis en train de travailler en C# (sous Windows 11) sur une fonction d'exploration d'arborescences (dossiers + fichiers). Cela fonctionne parfaitement,... sauf quand un chemin fichier dépasse la barre fatidique des 260 caractères (vieux serpent de mer, me direz vous !).

Ce que j'ai tenté sur les conseils de ChatGPT :

1. Modifier le registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem -> LongPathsEnabled DWORD 1
2. Utiliser le préfixe "\\?". Ca marche très bien pour des chemins locaux, mais pas pour des chemins réseau du style "\\MonServeur\MonDossier...".
3. D'après Microsoft, "À compter des applications exécutées sous .NET Framework 4.6.2, le .NET Framework prend en charge les chemins d’accès longs au-delà de 260 (ou MAX_PATH) caractères.". J'ai donc paramétré mon projet (et installé Visual Studio 2022 !) avec la version .NET Framework 4.8.

Mais rien n'y fait : je continue à avoir un message "<Problème...> - Le fichier '<Mon\chemin\trop\long>' est introuvable." lorsque mon appli tombe sur ce type de chemin.

Pour info, j'ai testé mon appli dans l'environnement Visual Studio (2019) en Visual Basic et là, pas de problème ! Les chemins longs sont parfaitement acceptés.

Je suis un peu désemparé . Auriez vous une idée SVP ?
Merci d'avance.

[StringBuilder]

Bonjour,

Sur quelles versions d'OS êtes-vous ? (machine cliente et serveur)

Avez-vous activé les noms longs sur le serveur aussi ?

Accessoirement, l'ensemble du Framework .NET est abandonné. La version 4.8.1 (serveur) et 4.8.2 (workstation) est la dernière version, et elle n'évoluera plus. Elle reste maintenue car partie intégrante des versions actuelles de Windows, mais n'a plus d'avenir : les prochaines versions de Windows pourraient ne plus la livrer par défaut, et donc se retrouver à terme incompatible.

Pourquoi ne pas miger vers .NET tout court ?
On en est à la version 8.0 qui est en LTS (la 9.0 est en beta).
On peut passer de Framework .NET à .NET très facilement (attention tout de même, il y a eu un peu de réorganisation des namespaces, et certains composant sont maintenant gérés sous forme de NuGet, ce qui oblige à intervenir sur le code, sans pour autant devoir réécrire grand chose).
.NET a l'avantage d'ête totalement multi-plateforme, tout en proposant toujours WinForms pour faire du desktop Windows (donc à nouveau, pas besoin de tout réécrire).

PS : par contre changer de version de .NET ne devrait probablement rien changer.

A noter aussi que d'utiliser des noms de fichiers long n'est pas une bonne idée en soit : de nombreux logiciels on la valeur MAX_PATH harcodée, à commencer par Microsoft Office, qui a même une valeur plus petite (218) ou OnDrive (520).

Il est préférable donc de rester sur des chemin assez courts.

[jcd1234]

Merci StringBuilder pour votre réponse... et vous avez vu juste !

En fait, la nuit porte conseil, j'ai trouvé moi-même la solution ce matin :
Je travaillais donc sous Visual Studio 2022 avec le .NET framework 4.8. En me levant ce matin, je me suis dit qu'en installant le .NET framework 8.0, cela résoudrait peut-être mon problème. Et bingo ! Ca a marché .

Pour ce qui est des noms longs, je suis bien d'accord avec vous qu'il vaut mieux les éviter. Ceci dit, mon expérience m'a montré qu'il est difficile de discipliner les utilisateurs, lesquels ont tendance à utiliser des noms explicites pour leurs fichiers et dossiers, donc des noms longs. D'autre part, ma future application traitant des arborescences de plus de 20000 fichiers, on y trouve immanquablement des noms longs dont on n'est pas responsables. Pour mon cas, c'était un fichier généré automatiquement par une sauvegarde Thunderbird.

Merci encore pour m'avoir accordé de votre temps pour mon problème.

[umfred]

Je travaillais donc sous Visual Studio 2022 avec le .NET framework 4.8. En me levant ce matin, je me suis dit qu'en installant le .NET framework 8.0, cela résoudrait peut-être mon problème. Et bingo ! Ca a marché .

Attention à la formulation, .NET 8.0 n'est pas de la famille de .NET Framework mais de la famille .NET Core (le Core a été abandonné en cours de route pour ne devenir que .NET)