La struttura delle directory di MSBuild limita le soluzioni alternative

Question

Qualcuno ha un metodo per superare il limite di 260 caratteri dello strumento MSBuild per la creazione di progetti e soluzioni di Visual Studio dalla riga di comando? Sto cercando di automatizzare la build utilizzando CruiseControl (CruiseControl.NET non è un'opzione, quindi sto cercando di collegarlo a normali script di formiche) e continuo a incorrere in problemi con la lunghezza dei percorsi. Per chiarire, il problema riguarda la lunghezza dei percorsi dei progetti a cui si fa riferimento nel file della soluzione, poiché lo strumento non comprime correttamente i percorsi :(

Ho anche provato a usare DevEnv che a volte funziona e talvolta genera un'eccezione, il che non è buono per una build automatizzata su una macchina separata. Quindi, per favore, non suggerire di usarlo come sostituto.

E per di più, il progetto funziona bene quando si utilizza Visual Studio tramite il normale IDE.

Answer 1

Sembra che sia una limitazione di MSBuild. Abbiamo avuto lo stesso problema e alla fine abbiamo dovuto accorciare i percorsi, perché non abbiamo trovato altre soluzioni che funzionassero correttamente.

Answer 2

Il comando SUBST sembra esistere, rimappando la radice di la tua cartella di build in una lettera di unità potrebbe salvare alcuni caratteri se la soluzione di Judah Himango non va bene.

Answer 3

Ho risolto un problema simile modificando il file CSPROJ:

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

Come risultato durante la compilazione CSC.EXE riceve il percorso completo anziché quello relativo.

Grazie a harrydev per indizio su come CSC.EXE opera con i percorsi.

Answer 4

Esistono due tipi di problemi di percorso lungo rilevanti per la creazione. Uno è rappresentato da percorsi non troppo lunghi, ma con un sacco di " .. \ " in loro. In genere, si tratta di valori HintPath di riferimenti. MSBuild dovrebbe normalizzare questi percorsi fino al di sotto del limite massimo, in modo che funzionino.

L'altro tipo di percorso è semplicemente troppo lungo. Mi dispiace, ma questi non funzioneranno. Dopo averlo esaminato un po ', il problema è che non c'è supporto API sufficiente per percorsi lunghi. Il team BCL (vedi il loro blog) ha avuto problemi simili. Solo alcune API di Win32 supportano il formato \? \. Strumenti di compilazione arbitrari, e probabilmente il 98% delle app là fuori, no; e peggio probabilmente si comporterebbe male (pensa a tutti i buffer dimensionati per MAX_PATH).

Siamo giunti alla conclusione che fino a quando non ci sarà un grande sforzo dell'ecosistema per far funzionare i percorsi lunghi, o Windows ha escogitato un modo ingegnoso per farli funzionare comunque (come i percorsi brevi che distruggono?) i percorsi lunghi non sono possibili per MSBuild da supportare. Le soluzioni alternative includono subst, come hai trovato; ma se il tuo albero è semplicemente troppo profondo, le uniche opzioni sono costruirlo in frammenti o abbreviare i nomi delle cartelle. Siamo spiacenti.

Dan / MSBuild

Answer 5

Ho riscontrato che il problema è che quando viene chiamato il compilatore C # (csc.exe) utilizza il percorso della directory dei progetti PROJECTDIRECTORY insieme al percorso di output OUTPUTPATH ??semplicemente aggiungendoli come:

  

PROJECTDIRECTORY + OutputPath

Tuttavia, se OUTPUTPATH ??è relativo, ad es. " .. \ .. \ Build \ ProjectName \ AnyCPU_Debug_Bin \ " e la directory del progetto è piuttosto lunga, quindi la lunghezza totale è più lunga di 259 caratteri poiché il percorso sarà:

  

ProjectPath + " .. \ .. \ costruire \ ProjectName \ AnyCPU_Debug_Bin \ "

invece di un percorso assoluto.

Se csc.exe creasse un percorso assoluto prima di chiamare le funzioni Win32, funzionerebbe. Poiché nel nostro caso la lunghezza del percorso assoluto è inferiore a 160 caratteri.

Per qualche ragione la chiamata a csc.exe da Visual Studio è quindi diversa da MSBuild rispetto a Visual Studio. Non so perché.

In ogni caso, il problema può essere risolto cambiando uno o entrambi i percorsi PROJECTDIRECTORY e / o OUTPUTPATH.

Answer 6

Hai provato i percorsi DOS? O il prefisso \\? \? Il blog del team .NET BCL ha maggiori informazioni.

Answer 7

Se la lunghezza del percorso è 260, allora c'è un avviso che risolve il riferimento, per 259 o 261 di questo errore non si verifica. Penso che ci sia un bug di msbuild.

Answer 8

So che esiste già una risposta accettata, ma ho avuto un problema diverso durante l'utilizzo di msbuild che mi ha dato lo stesso output di errore e mi ha portato a un inseguimento circolare di oca selvatica. Quindi, per i futuri googler, ecco:

Abbiamo un file batch che chiama msbuild , ma poiché la macchina di compilazione può costruire per più versioni di Visual Studio, ogni file batch chiama vcvarsall.bat prima che venga eseguito msbuild . Questo ha il cattivo effetto collaterale di riempire il percorso completamente pieno della stessa cosa ancora e ancora. Quando si riempie, viene visualizzato l'errore mostrato nella domanda sopra: La riga di input è troppo lunga. Una semplice ricerca su Google potrebbe farti pensare che i tuoi percorsi siano improvvisamente troppo lunghi per msbuild .

Nel mio caso, è stato semplice come uccidere la sessione di cmd.exe e riavviarlo, poiché ciò ha riportato le variabili di ambiente al loro stato nativo.