¿Cómo puede controlar los nombres de archivo para las referencias de servicio de .NET?

Question

Windows tiene una limitación de 259 caracteres en las rutas. Lamentablemente, esto nos está empezando a causar problemas debido a algunos de nuestros nombres de referencia de servicio.

Por ejemplo, tenemos nuestra sucursal TFS con un camino ya de largo, y luego las referencias de servicios .NET casi el doble de esta, ya que siempre utilice el espacio de nombres totalmente calificado como nombre de archivo:

Some.Really.Long.Fully.Qualified.Namespace.Service.Reference.Name.datasource

yo sepa , no puede cambiar el nombre de la referencia de servicio, pero Ihoping estoy equivocado. Se puede hacer esto?

Si no, ¿hay alguna otra solución posible a este molesto problema?

EDITAR: También, sé que una solución obvia sería acortar nuestros espacios de nombres y/o rutas, pero supongamos que no podemos hacer eso en este caso. :) Trato principalmente de averiguar cómo controlar los nombres de archivo para las referencias de servicio.

ACTUALIZACIÓN: El problema de raíz que estoy teniendo es que TFS no me permite obtener la última información sobre una rama en particular. Aquí está el error exacto:

TF205022: The following path contains more than the allowed 259 characters: [C:\Some-really-long-259-character-path-here]

Answer 1

Resulta que estos archivos .datasource pueden eliminarse, ya que no son necesarios para construir el proyecto. Así que simplemente hicimos un barrido de todos los archivos .datasource en TFS y los borramos.

This article habla más sobre esto.

Answer 2

259? de hecho es 32 k por NTFS pero Windows Explorer limita a "256", hay ciertas API de Windows que permiten crear y manejar rutas más largas hasta el límite real de NTFS ~ 32k, la potencia adecuada de 2, pero la mayoría del software realmente no usa esas API nativas ...

ver aquí: Maximum filename length in NTFS (Windows XP and Windows Vista)?.

Una posibilidad sería utilizar unión herramienta de Sys Internos y unión de la ruta de la rama larga a algo mucho más corta directamente en C#, todo debe entonces trabajar, ya que sólo se utilizaría rutas relativas, supongo.