10

Abbiamo una soluzione Visual Studio piuttosto complessa (57 progetti, 19 dei quali sono siti Web che non riescono a compilare quasi ogni volta quando attivati ​​premendo codice, ma poi attivano manualmente la build eIl sito Web di Visual Studio non riesce a intermittenza sul server CI

La soluzione contiene 57 progetti, 19 dei quali sono progetti di siti Web. (Non progetti di applicazioni Web, non esiste alcun file .csproj). Il resto sono librerie di classi e lavori in background. i progetti di siti Web sono strutturati nelle directory virtuali di IIS in un unico grande sistema di gestione dei contenuti multifunzione.

Il server di build è Hudson v1.395. Il comando utilizzato per creare è:

"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com" "SolutionName.sln" /rebuild Debug 

Quando la compilazione fallisce, lo fa sempre sulla stessa identica progetto di sito web, con lo stesso identico messaggio:

------ Rebuild All started: Project: C:\...\WebsiteName\, Configuration: Debug Any CPU ------ 
Validating Web Site 
: Build (web): The application domain in which the thread was running has been unloaded. 

Validation Complete 

Un Google Search for this message è attualmente meno disponibile. This link si avvicina di più al problema effettivo ma non ha alcuna risoluzione. Ovviamente non stiamo cambiando alcun file di soluzione durante la compilazione perché si sta verificando sul build server.

Quando non riesce, si innescano la costruzione manualmente, e otteniamo come ci aspettiamo (mi dispiace, redatto):

------ Rebuild All started: Project: C:\...\News2\, Configuration: Debug Any CPU ------ 
Validating Web Site 
Building directory '/WebsiteName/Dir1/Dir2/'. 
Building directory '/WebsiteName/'. 
Building directory '/WebsiteName/Dir3/'. 
// 22 more but you get the point 

// A few warnings caused by our own use of the ObsoleteAttribute, nothing to be concerned about 
Validation Complete 

Che cosa ha potuto causare questo dominio di applicazione scaricata messaggio?

Alcune altre note:

  • abbiamo pensato che potrebbe essere Hudson a corto di memoria, perché noi osserviamo java che perde un bel po '. Quindi, abbiamo aggiunto un'attività per riavviare il servizio Hudson ogni mattina alle 6 del mattino. Anche con questa e una quantità ragionevole di memoria disponibile pronta per l'uso durante la compilazione, ha comunque fallito.
  • Una spinta allo stesso repository causa anche la creazione di una soluzione molto più semplice (solo 22 progetti, nessun progetto di sito Web) allo stesso tempo. Quello ha sempre successo. Inoltre, l'attivazione manuale di entrambi per l'esecuzione nello stesso momento ha esito positivo.
  • So che dovremmo aggiornare Hudson ma questo è sempre uno di quei progetti di backburner per i quali non abbiamo mai avuto il tempo. In ogni caso, ritengo abbastanza forte che si tratti di un problema di Visual Studio/MSBuild, non di un problema di Hudson.

Edit 1: MSBuild

Il problema con MSBuild è che ci sono tanti piccoli capricci che differiscono da un accumulo in Visual Studio. È estremamente frustrante per una soluzione compilare in Visual Studio su un computer dello sviluppatore e quindi fallire sul server di generazione. Anche l'output di msbuild è drasticamente diverso (molto più dettagliato per una cosa) da ciò che i nostri sviluppatori vedono nella finestra di output della build. Ci sono altri flag a riga di comando che rendono l'output di MSBuild più in linea con quello che si ottiene nella finestra di build di Visual Studio?

Ci sono anche altre cose che sono imbarazzanti. Se ti capita di avere una cartella della soluzione con lo stesso nome di un progetto, MSBuild genera un errore ma Visual Studio lo gestisce bene. Quelle sono le peculiarità che ti fanno davvero strappare i capelli.

risposta

2

Non ho molta familiarità con Hudson o con il progetto di un sito web (utilizzo TeamCity e progetti di applicazioni web), ma ho pensato di buttare un paio di cose là fuori per vedere se sarebbe stato d'aiuto.

Hai provato a creare la soluzione utilizzando MSBuild direttamente invece di utilizzare Visual Studio? Il comando sarebbe simile a questa:

%windir%\Microsoft.NET\Framework\<version>\MSBuild SolutionName.sln /t:Rebuild /p:configuration=debug 

ho notato che non stavano passando l'opzione della riga di comando per Visual Studio per chiudere dopo la costruzione è completa/RunExit MSDN Link Quindi potrebbe essere che l'IDE di Visual Studio si apre sul tuo server di build per ogni build e non in chiusura? Potrei vedere più istanze dell'IDE che hanno la stessa soluzione aperta a causare problemi.

Vorrei raccomandare se possibile eseguire la build utilizzando MSBuild anziché Visual Studio a meno che non si abbia una dipendenza da qualcosa all'interno dell'IDE. Dovresti, per lo meno, ottenere tempi di compilazione più rapidi perché non dovrai caricare Visual Studio e rimuoverà un livello di complessità nel processo di compilazione.

Spero che questo aiuto!

+0

Per quanto riguarda MSBuild, vedere "Modifica 1" che ho aggiunto alla mia domanda. Anche se non è la mia opzione preferita, ci proverò. Proverò anche a RunExit, anche se non osserviamo le istanze di devenv che si aggirano sul server. Anche un chiarimento - anche se sono * da * lo stesso repository, entrambe le soluzioni sono cloni completi quindi non c'è alcuna condivisione di alcun tipo tra le due istanze di sviluppo simultanee. –

+0

per quanto riguarda i livelli di registrazione su MSBuild, è possibile modificarlo utilizzando il flag/verbosity [MSDN link] (http://msdn.microsoft.com/en-us/library/ms164311.aspx) –

+0

** Questa opzione non è disponibile per i progetti Visual Studio 7.0-9.0 (2003-2008) e C++! ** (VS 10.0 ha convertito progetti C++ in msbuild, quindi è possibile lì). –

2

Un'altra build simultanea in esecuzione come risultato dello stesso checkin sembra essere correlata. Una risorsa che va via nel bel mezzo della mia build mentre si esegue una generazione correlata mi rende sospettoso della build correlata.

So che hai detto che puoi eseguirli allo stesso tempo manualmente e tutto va bene. Però mi sembra una condizione di competizione. Prova a disabilitare il trigger automatico nei progetti più piccoli e a eseguire il controllo di integrità per assicurarti che non ti stia rovinando.

Immagino che se non lo sospettassi, non lo avresti menzionato nel tuo post. Discutilo.

6

Ho avuto un problema con build C++ su Hudson/Jenkins che è probabilmente correlato, se hai due build che vanno in una volta, allora possono accadere cose brutte.

Questo perché Hudson/Jenkins eseguirà un killer del processo per eliminare i processi alla fine di una build e MsBuild/VisualStudio condividerà alcuni processi comuni tra le build.

Il vero problema che ho avuto con il C++ si costruisce manifesta come un altro errore:

fatal error C1090: PDB API call failed, 
error code '23' : '( 

Il problema è stato sollevato qui:

https://issues.jenkins-ci.org/browse/JENKINS-9104

Spegnendo il killer albero processo può risolvere il problema.

Problemi correlati