Soluciones de límite de estructura de directorios de MSBuild

Question

¿Alguien tiene un método para superar el límite de 260 caracteres de la herramienta MSBuild para crear proyectos y soluciones de Visual Studio desde la línea de comandos? Estoy tratando de automatizar la compilación utilizando CruiseControl (CruiseControl.NET no es una opción, así que estoy tratando de vincularlo con los scripts de hormigas normales) y sigo teniendo problemas con la longitud de las rutas. Para aclarar, el problema está en la longitud de las rutas de los proyectos a los que se hace referencia en el archivo de la solución, ya que la herramienta no colapsa las rutas correctamente :(

También he intentado usar DevEnv, que a veces funciona y otras lanza una excepción, lo que no es bueno para una compilación automatizada en una máquina separada. Así que, por favor, no sugieras usar esto como un reemplazo.

Y para colmo, el proyecto funciona bien cuando se usa Visual Studio a través del IDE normal.

Answer 1

Parece que es una limitación de MSBuild. Tuvimos el mismo problema y, al final, tuvimos que acortar las rutas porque no encontramos ninguna otra solución que funcionara correctamente.

Answer 2

El comando SUBST todavía parece existir, por lo que reasigna la raíz de su carpeta de compilación en una letra de unidad puede guardar algunos caracteres si la solución de Judah Himango no es buena.

Answer 3

Resolví un problema similar ajustando el archivo CSPROJ:

<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\Intermediate\$(AssemblyName)_$(ProjectGuid)\'))</BaseIntermediateOutputPath>

Como resultado durante la compilación, CSC.EXE recibe una ruta completa en lugar de una relativa.

Gracias a harrydev por la pista sobre cómo CSC.EXE opera con las rutas.

Answer 4

Hay dos tipos de problemas de ruta larga relevantes para construir. Una de ellas son las rutas que no son realmente demasiado largas, pero tienen un montón de " .. \ " en ellos. Por lo general, estos son valores HintPath de referencias. MSBuild debería normalizar estas rutas por debajo del límite máximo, para que funcionen.

El otro tipo de camino es simplemente demasiado largo. Lo siento, pero esto simplemente no funcionará. Después de verlo un poco, el problema es que simplemente no hay suficiente soporte de API para rutas largas. El equipo de BCL (ver su blog) tuvo problemas similares. Solo algunas de las API de Win32 admiten el formato \? \. Las herramientas de compilación arbitrarias, y probablemente el 98% de las aplicaciones que existen, no lo hacen; y peor aún se comportaría mal (piense en todos los búferes dimensionados para MAX_PATH).

Llegamos a la conclusión de que hasta que no haya un gran esfuerzo por parte del ecosistema para hacer que los caminos largos funcionen, o Windows encuentra alguna forma ingeniosa de hacer que funcionen de todos modos (como los caminos cortos que destrozan?) los caminos largos simplemente no son posibles para MSBuild para apoyar. Las soluciones incluyen subst, como has encontrado; pero si su árbol simplemente es demasiado profundo, sus únicas opciones son construirlo en fragmentos o acortar los nombres de las carpetas. Lo siento.

Dan / MSBuild

Answer 5

Descubrí que el problema es que cuando se llama al compilador C # (csc.exe), utiliza la ruta de directorio de proyectos PROJECTDIRECTORY junto con la ruta de salida OUTPUTPATH ??simplemente agregándolos como:

  

DIRECTORIO DE PROYECTOS + RUTA DE SALIDA

Sin embargo, si OUTPUTPATH ??es relativo, es decir, " .. \ .. \ Build \ ProjectName \ AnyCPU_Debug_Bin \ " y el directorio del proyecto es bastante largo, entonces la longitud total es más larga que 259 caracteres ya que la ruta será:

  

PROJECTPATH ??+ " .. \ .. \ Build \ ProjectName \ AnyCPU_Debug_Bin \ "

en lugar de una ruta absoluta.

Si csc.exe haría una ruta absoluta antes de llamar a las funciones de Win32, esto funcionaría. Como en nuestro caso la longitud absoluta de la ruta es inferior a 160 caracteres.

Por alguna razón, la llamada a csc.exe desde Visual Studio es diferente de MSBuild que de Visual Studio. No sé por qué.

En cualquier caso, el problema se puede resolver cambiando las rutas de PROJECTDIRECTORY y / o OUTPUTPATH, o ambas.

Answer 6

¿Has probado las rutas de DOS? ¿O el prefijo \\? \? El .NET blog del equipo de BCL tiene más información.

Answer 7

Si la longitud del camino es 260, entonces hay una referencia de resolución de advertencia, para 259 o 261 de este error no se produce. Creo que hay un error de msbuild.

Answer 8

Sé que ya hay una respuesta aceptada, pero tuve un problema diferente al utilizar msbuild que me dio la misma salida de error y me llevó a una persecución circular de ganso salvaje. Entonces, para futuros googlers, aquí va:

Tenemos un archivo por lotes que llama a msbuild , pero como la máquina de compilación puede compilar para múltiples versiones de Visual Studio, cada archivo por lotes llama a vcvarsall.bat antes de que se ejecute msbuild . Esto tiene el desagradable efecto secundario de rellenar el camino completamente lleno de lo mismo una y otra vez. Cuando se llena, aparece el error que se muestra en la pregunta anterior: La línea de entrada es demasiado larga. Una simple búsqueda en Google puede hacerte pensar que tus rutas son repentinamente demasiado largas para msbuild .

En mi caso, fue tan simple como matar la sesión de cmd.exe y reiniciar, ya que esto revertía las variables de entorno a su estado nativo.