Microsoft (TFS) Build - Server - Der Typ oder Namespace - Name '...' existiert nicht im Namespace '...' (fehlt eine Assembly - Referenz?)

Question

Ich arbeite an der Einrichtung eines Buildservers für unsere Mannschaft.

Hintergrund
Wir verwenden Microsoft Visual Studio 2010 Ultimate. Unser Produkt enthält C# -Code (hauptsächlich), externe DLLs und C-Code. Wir arbeiten mit .Net 4.0 und haben mehr als 70 Projekte.

Wir mit 3 Zweigen unseres Code arbeiten:

• Produktion branche (was zur Zeit freigegeben wird)
• Test-branche (Hot Fixes, Fehlerbehebung Endbenutzers Tests)
• Entwicklung branche (neue Einträge hinzufügen)

Alle Zweige sind unter TF Source Control.

Tor
Was wir wollen, ist ein Build-Server haben alle Unit-Tests für alle Zweige einmal pro Tag zu erstellen und auszuführen, sollte der Build-Server den Code in der Quellcodeverwaltung verwenden. Unser Ziel ist eine schnelle Standardfehlererkennung. Wir würden so wenig wie keine Wartung des Build-Servers bevorzugen.

Wir werden nicht die Builds verwenden, die der Buildserver produziert, alles was wir wollen ist, den Buildserver zu verwenden, um unsere Zweige kontinuierlich zu erstellen und zu testen.

Was eingerichtet ist
Es gibt derzeit zwei die Build-Definition eingerichtet, eine für den Test-Branche und eine für die Entwicklung Branche, bauen beide Definitionen den Code aus dem Quellensteuer nehmen (das Teil funktioniert alles gut), aber hier beginnt der Spaß.

Problem
Die Test-Branche können alle fein Erstellen und Ausführen von Unit-Tests.

Die Entwicklung Branche kann aufgrund einem aufbauen (oder wie 5) Fehler:

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

Der Fehler ist für das Projekt X refereing Y. Beide Projekt X und Y für C# 4.0 Projekte zu projizieren, und Wir haben die volle Kontrolle über beide, sowohl X als auch Y werden zu DLLs kompiliert. Projekt Y enthält eine Schnittstelle, die die Klassen in Projekt X implementieren.

Das lästige Detail ist, gibt es keinen Unterschied in der Test Branche und Development Brance für entweder Projekt X oder Y. Die beiden Projekte waren in den letzten 3 Monaten völlig identisch.

Die Frage ist also, warum funktioniert es in der Testbranche, aber nicht in der Entwicklung branche?

Ich habe getestet:
- Die Projekte sind richtig miteinander refered. - Alle 3 Zweige haben kein Problem, auf eigenen/irgendwelchen meiner Mitarbeiterentwicklungsmaschinen zu bauen (wir haben auf 5 verschiedenen Maschinen getestet). - Ich habe versucht, das gesamte X-Projekt zu löschen und neu zu erstellen, hat nicht funktioniert. - Ich habe versucht, das ganze Y-Projekt zu löschen und neu zu erstellen, hat nicht funktioniert. - Ich habe versucht, den Namespace für Projekt X-Projekt und seine Klassen zu ändern, hat nicht funktioniert. - Ich habe versucht, den Namespace für Projekt Y-Projekt und seine Klassen zu ändern, hat nicht funktioniert. - (Ich habe sogar meine Entwicklungsmaschine neu gestartet) - Alle Änderungen wurden immer in die Quellcodeverwaltung eingecheckt, wo nach dem Buildserver gesetzt wurde zu bauen.

Zusatzinformationen
Ich habe um in den Logging-Dateien gegraben und fand einige interessante Details, dann ist dies für die Einzelheiten der Baumaßnahme X in der Entwicklung 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. 

Aber dann in der 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 

Wo im Test Brance für die gleiche Aufgabe

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 

So fühlt es sich wie es aus irgendeinem Grund nur „vergisst“ der Verweis von Projekt X zu Y. Projekt

Hilfe

Answer 1

Ich hatte das gleiche Problem.

Es dauerte einige Stunden, um herauszufinden, dass das Problem in diesem Fall war nicht meine Schuld :-)

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

Dieses Problem tritt aufgrund eines Fehlers in der Path.GetFullPath in .NET Framework-Bibliothek. Diese ist ein bekanntes Problem in Visual Studio 2010

Symptome:

..., wenn Sie versuchen, eine Lösung zu bauen mit mehreren Projekte, bei denen es Abhängigkeitsbeziehungen zwischen ihnen besteht, in bestimmte Bedingungen ein Build fehlschlägt mit der folgenden Fehlermeldung.

Fehlermeldung: „C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (1200, 9): Warnung: Das referenzierte Projekt‚Relative Pfad zum verwies Projekt aus Das aktuelle Verzeichnis ist nicht vorhanden.

Ein Build schlägt mit der obigen Fehlermeldung fehl, wenn die folgenden Bedingungen erfüllt sind: .

1. Sie haben eine Lösung mit mehreren Projekten, in denen Abhängigkeitsbeziehungen zwischen ihnen bestehen.
2. Die Summe der Länge folgt zwei Pfad genau zu 259 Zeichen (= MAX_PATH - 1) aufaddiert

1) den Pfad eines Verzeichnisses Referenzierung Projekt.2) Der relative Pfad zu einem referenzierten Projekt aus dem aktuellen Verzeichnis (= ein referenzierendes Projektverzeichnis).

HINWEIS: MAX_PATH ist die maximale Pfadlänge, die von Windows API definiert wird, und ist auf 260 Zeichen festgelegt.

Umgehung:

, um dieses Problem zu umgehen, können Sie Pfadlänge ändern und stellen Sie sicher, , dass die Summe der beiden folgenden Weglänge nicht zu 259 Zeichen aufaddiert wird.

1. Der Pfad des Verzeichnisses eines referenzierenden Projekts.

2. Der relative Pfad zu einem referenzierten Projekt aus dem aktuellen Verzeichnis (= ein referenzierendes Projektverzeichnis).

Answer 2

traf ich den kürzlich gleichen Fehler. Die Lösung, die lokal in VS2010 erstellt wurde, ist in Ordnung, aber auf dem Build-Server ist sie durchgehend fehlgeschlagen. Am Ende wurde die MSBuild-Definition auf die Release x86 Konfiguration festgelegt, aber das beschwerde Projekt referenzierte eine Assembly in bin \ x86 \ Debug statt bin \ x86 \ Release.

Überprüfen der Release Version der Assembly anstelle der Version Debug verwiesen (und bei Bedarf zu korrigieren) schien für mich den Trick zu tun.

Answer 3

Ich hatte gerade ein ähnliches Problem und es endete damit, dass der Entwickler, der zuletzt an dem Code gearbeitet hat, entschieden hat, Referenzen auf einige DLLs im obj \ debug-Verzeichnis hinzuzufügen.

Answer 4

Das Problem an meinem Ende war leider ganz anders.

Ich habe zwei verschiedene Versionen desselben gemeinsamen Codes erstellt, einen für .Net4 und einen anderen für Silverlight 5, mit demselben Dateinamen (.Framework.dll).

Da der Build-Server standardmäßig alles im selben Ordner ausgibt, überschrieb die Silverlight-Version der Assembly die .Net4-Version, weil msbuild sich entschied, sie später zu erstellen. Dies verursachte ein Problem, sobald das nächste Projekt in der Lösung erstellt wurde, das von einigen Klassen abhängig war, die auf der .Net4-Version der DLL verfügbar waren, aber nicht auf der Silverlight-Version.

Ich beendete die Aufteilung der Projekte in mehrere Lösungen und setzen die Option 'Solution Specific Build Outputs' auf 'true' auf der Build-Definition 'Prozess' Registerkarte.

Answer 5

Ich hatte ein sehr ähnliches Problem. Ich habe festgestellt, dass die Plattform im Configuration Manager unter Release Configuration auf Any CPU gesetzt war und das Kontrollkästchen Build nicht aktiviert war.

Die Plattform auf x86 setzen (da alle meine anderen Projekte aus Legacy-Gründen darauf eingestellt sind) und sicherstellen, dass das Projekt unter dieser Konfiguration auf Build gesetzt wurde, behebt mein Problem.

Answer 6

Es ist eine etwas alte Frage, aber ich bin gerade auf ein ähnliches Problem gestoßen und in meinem Fall war es die falsche referenzierte Projekt-ID (nennen wir es B) in der .cproj-Datei des fehlgeschlagenen Projekts (Projekt A). Ursprünglich habe ich das Projekt A von einer anderen Lösung kopiert und in die Lösung, mit der ich gerade arbeite, aufgenommen. Das angesprochene Projekt B war ebenfalls in beiden Lösungen so Visual Studio automatisch aufgelöst Referenzen obwohl in dem .cproj referenzierten Projekt B A noch in der Lösung auf den B zeigt ich mich von kopiert: Weirdly

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

, Visuell Studio würde die falsche ID ignorieren und vermutlich nur den Pfad verwenden, damit keine Buildfehler auftreten und die korrekte DLL in der Ablage von Projekt A angezeigt wird. MSBuild auf meinem Build-Server wäre jedoch nicht so liberal. Um es zu beheben, können Sie entweder .cproj Datei in einem Texteditor bearbeiten oder einfach Referenzen entfernen und fügen Sie sie zurück, um sicherzustellen, dass sie in Ihrer aktuellen Lösung sind.