Microsoft (TFS) Build server - Il tipo o il nome dello spazio dei nomi '...' non esiste nello spazio dei nomi '...' (manca un riferimento all'assembly?)

Question

Sto lavorando alla creazione di un buildserver per il nostro squadra.

Sfondo
Stiamo utilizzando Microsoft Visual Studio 2010 Ultimate. Il nostro prodotto contiene codice C# (principalmente), DLL esterne e codice C. Stiamo lavorando con .Net 4.0 e abbiamo più di 70 progetti.

Stiamo lavorando con 3 rami del nostro codice:

• Produzione branche (ciò che è attualmente rilasciato)
• prova branche (hot fix, correzioni di bug, test utente finale)
• Sviluppo branche (aggiungendo nuovi feticci)

Tutti i rami sono sotto il controllo della sorgente TF.

Goal
Quello che vogliamo è avere un server di build per creare ed eseguire tutti i test di unità per tutti i rami una volta al giorno, il server di generazione dovrebbe utilizzare il codice nel controllo del codice sorgente. Il nostro obiettivo è avere un rapido rilevamento degli errori standard. Preferiremmo il mantenimento del server di compilazione come minimo o nullo.

Non useremo le build prodotte da buildserver, tutto ciò che vogliamo è utilizzare il build server per creare e testare continuamente le nostre filiali.

Cosa è impostato
momento non ci sono istituiti due la definizione di compilazione, uno per il Branche test e uno per la Branche sviluppo, sia costruire definizioni che prendono il codice dal controllo del codice sorgente (che parte funziona tutto bene), ma qui è dove inizia il divertimento.

Problema
La Branche test può costruire e unit test run tutti bene.

La Branche Lo sviluppo non può costruire a causa di un (o come 5 di) errori:

The type or namespace name 'XXX' does not exist in the namespace 'YYY' (are you missing an assembly reference?) 

L'errore è per il progetto X refereing a progetto Y. Entrambi progetto X e Y è C# .Net 4.0 progetti e abbiamo il pieno controllo su entrambi, sia X che Y sono compilati in DLL. Il progetto Y contiene un'interfaccia che le classi del progetto X stanno implementando.

Il fastidioso dettaglio è che non ci sono differenze nel Test Branche e nello Sviluppo Brance per entrambi i progetti X o Y. I due progetti sono stati completamente identici negli ultimi 3 mesi.

Quindi la domanda è: perché funziona nel Test Branche ma non nella branca di sviluppo?

Ho testato:
- I progetti sono correttamente riferiti l'uno all'altro. - Tutti e 3 i rami non hanno problemi a costruire da soli/nessuno dei miei computer di sviluppo dei miei colleghi (abbiamo testato su 5 macchine diverse). - Ho provato a cancellare l'intero progetto X e ricrearlo, non ha funzionato. - Ho provato a cancellare l'intero progetto Y e ricrearlo, non ha funzionato. - Ho provato a cambiare lo spazio dei nomi per il progetto del progetto X e le sue classi, non ha funzionato. - Ho provato a cambiare lo spazio dei nomi per il progetto del progetto Y e le sue classi, non ha funzionato. - (Ho anche riavviato la mia macchina di sviluppo) - Tutte le modifiche sono sempre state controllate nel controllo del codice sorgente dopo che il build server è stato impostato per la compilazione.

Ulteriori informazioni
Ho scavato intorno nelle file di log e ho trovato alcuni dettagli interessting, questo è per i dettagli del progetto di costruzione X nello Sviluppo Branche

Task "AssignProjectConfiguration" 
    Project reference "..\..\A" has been assigned the "Debug|x86" configuration. 
    Project reference "..\..\Y" has been assigned the "Debug|x86" configuration. (can see there is a project Y) 
    Project reference "..\..\B" has been assigned the "Debug|x86" configuration. 

Ma poi nel Task “ResolveAssemblyReference”

Task "ResolveAssemblyReference" 
    TargetFrameworkMoniker: 
     .NETFramework,Version=v4.0 
    TargetFrameworkMonikerDisplayName: 
     .NET Framework 4 
    TargetedRuntimeVersion: 
     v4.0.30319 
    Assemblies: 
     System 
     System.Xml.Linq 
     System.Data.DataSetExtensions 
     Microsoft.CSharp 
     System.Data 
     System.Xml 
     System.Core 
    AssemblyFiles: 
     C:\Builds\1\A 
     C:\Builds\1\B 
(----- Missing project Y -----) 
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll 

Dove nel Brance prova per lo stesso compito

Task "ResolveAssemblyReference" 
    TargetFrameworkMoniker: 
     .NETFramework,Version=v4.0 
    TargetFrameworkMonikerDisplayName: 
     .NET Framework 4 
    TargetedRuntimeVersion: 
     v4.0.30319 
    Assemblies: 
     System 
     System.Data.Entity 
     System.Xml.Linq 
     System.Data.DataSetExtensions 
     Microsoft.CSharp 
     System.Data 
     System.Xml 
     System.Core 
    AssemblyFiles: 
     C:\Builds\1\A 
     C:\Builds\1\B 
     C:\Builds\1\Y (There it is) 
    C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll 

così ci si sente come se per qualche motivo solo “dimentica” il riferimento da progetto a progetto X Y.

Aiuto

Answer 1

Ho avuto lo stesso problema.

ci ho messo qualche ora per scoprire che in questo caso il problema non è stata colpa mia :-)

http://support.microsoft.com/kb/2516078:

Questo problema si verifica a causa di un bug nel Path.GetFullPath in Libreria .NET Framework. Questo è un problema noto in Visual Studio 2010

Sintomi:

... quando si tenta di creare una soluzione con più progetti in cui esiste relazioni di dipendenza tra di loro, in condizioni specifiche che una build non riesce con il seguente messaggio di errore.

Messaggio

errore: “C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (1200, 9): avviso: Il progetto di riferimento 'percorso relativo al progetto di riferimento da la directory corrente "non esiste."

Una generazione non riesce con il messaggio di errore sopra riportato quando sono soddisfatte le seguenti condizioni .

1. Si dispone di una soluzione con più progetti in cui esistono relazioni di dipendenza tra di loro.
2. La somma delle seguenti due lunghezza del percorso è esattamente aggiunti fino a 259 caratteri (= MAX_PATH - 1)

1) Il percorso della directory di un progetto di riferimento.2) Il percorso relativo a un progetto di riferimento dalla directory corrente (= una directory di progetto di riferimento ).

NOTA: MAX_PATH è la lunghezza massima del percorso definita dall'API di Windows e è impostata su 260 caratteri.

Soluzione:

Per risolvere questo problema, è possibile modificare la lunghezza del percorso e assicurarsi che la somma dei seguenti due lunghezza del percorso non viene aggiunto fino a 259 caratteri.

1. Il percorso di una directory del progetto di riferimento.

2. Il percorso relativo a un progetto di riferimento dalla directory corrente (= una directory di progetto di riferimento ).

Answer 2

ho incontrato lo stesso errore di recente. La soluzione creata localmente in VS2010 va bene, ma non è riuscita costantemente sul server di build. Alla fine, la definizione MSBuild era impostata sulla configurazione Release x86, ma il progetto lamentoso faceva riferimento a un assembly in bin \ x86 \ Debug, anziché bin \ x86 \ Release.

Verifica della rilascio versione dell'assembly è stato fatto riferimento al posto del di debug versione (e correggere, se necessario) sembrava fare il trucco per me.

Answer 3

Ho appena avuto un problema simile e ha finito per essere lo sviluppatore che ha lavorato per ultimo sul codice ha deciso di aggiungere riferimenti ad alcune DLL nella directory obj \ debug.

Answer 4

Purtroppo il problema alla fine era completamente diverso.

Stavo creando due versioni diverse dello stesso codice comune, una per .Net4 e un'altra per Silverlight 5, con lo stesso nome file (.Framework.dll).

Poiché il server di generazione restituisce tutto nella stessa cartella per impostazione predefinita, la versione di Silverlight dell'assembly ha terminato la sovrascrittura di .Net4 perché msbuild ha deciso di crearlo in un secondo momento. Ciò ha causato un problema non appena è stato creato il progetto successivo nella soluzione, che dipendeva da alcune classi disponibili nella versione .Net4 della dll, ma non da quella di Silverlight.

Alla fine ho suddiviso i progetti in più soluzioni e ho impostato l'opzione "Output di generazione specifica della soluzione" su true nella scheda "Processo" della definizione build.

Answer 5

Ho avuto un problema molto simile. Ho trovato che in Configuration Manager, sotto la configurazione di rilascio, la piattaforma era impostata su Any CPU e la casella di controllo Build non era selezionata.

L'impostazione della piattaforma su x86 (dato che tutti i miei altri progetti sono impostati per motivi legacy) e l'accertamento che il progetto fosse impostato su Build sotto questa configurazione ha risolto il problema.

Answer 6

È una domanda un po 'vecchia, ma ho appena riscontrato un problema simile e nel mio caso era l'ID del progetto di riferimento sbagliato (chiamiamolo B) nel file .cproj del progetto che stava fallendo (progetto A). Originariamente, ho copiato il progetto A da un'altra soluzione e l'ho incluso nella soluzione con cui sto lavorando ora. Il progetto di riferimento B era presente anche in entrambe le soluzioni in modo che Visual Studio riferimenti risolti automaticamente anche se nel Un .cproj riferimento del progetto B era ancora rivolta verso la B nella soluzione che ho copiato da:

<ProjectReference Include="..\B.csproj"> 
    <Project>{F3006530-D421-4A89-AA8B-376DBAA31E03}</Project> - wrong Id! 
    <Name>ProjectB</Name> 
</ProjectReference> 

Stranamente, Visual Studio ignorerebbe l'ID errato e presumibilmente utilizzerà il percorso solo per evitare errori di compilazione e la dll corretta nel bin del progetto A. MSBuild sul mio server di build non sarebbe comunque così liberale. Per risolvere il problema è possibile modificare il file .cproj in un editor di testo o semplicemente rimuovere i riferimenti e aggiungerli per assicurarsi che siano nella soluzione corrente.