Wie kann ich die Ursache dieses TFS Automated Build Error verfolgen?

Question

Ich habe eine Lösung, die ein Website-Projekt und mehrere Projekte enthält, die Support-Klassen enthalten. Jedes Projekt hat eine eigene Grundfunktion: Konfiguration, Daten, Identität, Business Objekte usw. Wenn ich die Lösung in VS2008 öffne, baut sie perfekt auf. Es funktioniert, läuft, debuggt und erfährt keine Kompilierungs- oder JIT-Ausnahmen.

Nachdem in TFS 2010 eine automatisierte Builddefinition generiert wurde, werden alle untergeordneten Projekte in der Build ausgeführt und kompiliert. Sie sind alle auf "Debuggen | Gemischte Plattformen" ausgerichtet, da die Dokumentation, die ich lese, um meinen Fehler aufzuspüren, anzeigt, dass dies für Website-Projekte erforderlich ist. Ich kann im Build-Protokoll sehen, wo alle frisch kompilierten Bibliotheken und alle Bibliotheken von Drittanbietern sowohl in das Verzeichnis \Binaries als auch in das Verzeichnis \bin der Website kopiert werden. Dann werden die nächsten Zeilen im Protokoll sind:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler.exe -v /MySolution -p ..\MySolution\ -u -f -d -fixednames D:\TFS\b\308\Binaries\_PublishedWebsites\MySolution\ 
D:\TFS\b\308\Sources\MySolution\SomeFolder\SomePage.aspx.vb(15): error BC30456: 'MyProperty' is not a member of 'Some_UserControl_ForPage'. [D:\TFS\b\308\Sources\Solution Files\MySolution.sln] 
Done Building Project "D:\TFS\b\308\Sources\Solution Files\MySolution.sln" (default targets) -- FAILED. 

Build FAILED. 

"D:\TFS\b\308\Sources\Solution Files\MySolution.sln" (default target) (1) -> 
(MySolution target) -> 
    D:\TFS\b\308\Sources\MySolution\SomeFolder\SomePage.aspx.vb(15): error BC30456: 'MyProperty' is not a member of 'Some_UserControl_ForPage'. [D:\TFS\b\308\Sources\Solution Files\MySolution.sln] 

Das Anwesen in Frage für die Steuerung Benutzer gehört zu einer „Großeltern“ Vererbung. Das Steuerelement erbt ein benutzerdefiniertes WebUserControl in der Business-Objektbibliothek. Diese Klasse wiederum erbt von einem weniger spezifischen WebUserControl, das über diese grundlegende Eigenschaft verfügt. Wenn die Codezeile auskommentiert wird, ändert sich der Fehler, aber es ist nur ein weiterer "nicht möglich" -Fehler, der weiter unten in der Buildkette auftritt.

Wir haben andere Website-Projekte erfolgreich automatisch Build-und Bereitstellung von diesem Build-Agent in allen Frameworks 2.0 +. Wenn ich verschiedene Eigenschaften der Builddefinition (Arbeitsbereich usw.) ändere oder die Konfiguration des Builds in der Lösung selbst ändere, bewirke dies keine Änderung des Verhaltens. Wenn der Build abgeschlossen ist, landen alle erfolgreich erstellten Projekte im Build-Ordner. Außerdem enthält diese Lösung ein zweites, weniger komplexes Website-Projekt, das erfolgreich erstellt wird und im Ordner _PublishedWebsites des Build-Ordners endet.

Answer 1

Der erste Kurs war das Deaktivieren der Use fixed naming and single page assemblies Einstellung der Website-Eigenschaften. Dies beseitigte den physikalischen Fehler. Dies war ein Swag von einem Kollegen und nicht eine berechnete Bewegung, aber meine beste Vermutung ist, dass TFS die verschachtelten Referenzen aus irgendeinem Grund nicht auflösen kann. Während dies den Referenzfehler beseitigte, wurde ein neuer Fehler angezeigt, der einen mehrdeutigen Namespace in einem Benutzersteuerelement anzeigt. Die Annahme ist, dass, da das Website-Projekt nicht mehr auf einzelne Seiten-Assemblies beschränkt ist, möglicherweise mehrere Kopien erzeugt werden (warum ist es jenseits von mir) und dies führt zu der Mehrdeutigkeit.

Ich verstehe nicht vollständig die Ins und Outs dieser Lösung, aber nachdem ich über das Problem in this blog article by Aaron Hallberg gelesen habe, verstehe ich, gibt es Unterschiede zwischen dem Compiler wie es in der IDE und dem Compiler ausgeführt wird, wie es auf dem ausgeführt wird automatischer Build-Agent Um seine Antwort zusammenzufassen, injiziert die IDE dem MSBuild für Websites automatisch kein -u. Da TFS jedoch nur die Lösung und nicht das Website-Projekt betrachtet, sucht es nach der Einstellung Debug.AspNetCompiler.Updateable. Wenn diese Einstellung geändert wird, führt dies möglicherweise zu mehrdeutigen Namespaces in Steuerelementen. Ich verstehe nicht warum und das Lesen seines Blogposts hat mir nichts klar gemacht.

Durch das Deaktivieren der Allow this precompiled site to be updated auf den Eigenschaftenseiten der Website konnte die Website ordnungsgemäß erstellt werden, und da es sich nicht um eine vorkompilierte Site handelt, hatte dies keine nachteiligen Auswirkungen auf den Build.