2009-04-16 15 views
2

Derzeit sind die Msbuild-Protokolle für Teambuilding erschreckend, da sie nur Text sind und sehr schwer zu lesen sind. Auch die von meinem Build erstellten sind ca. 30 MB groß und brauchen ziemlich lange, um heruntergeladen zu werden (unser TFS-Server befindet sich in unserem Datacenter).Gibt es eine bessere Möglichkeit, Teambuild-Protokolle anzuzeigen?

Kennt jemand eine Möglichkeit, diese Protokolle einfacher anzuzeigen, vorzugsweise mit TFS oder TFS WebAccess integriert?

Antwort

2

einen Blick auf die folgenden Blog-Post Take I vor einer Weile tat

http://www.woodwardweb.com/teamprise/000415.html

Dies beschreibt, wie eine einfache ASP.NET-Seite erstellen, die über Sie streamen die Inhalte der Protokolldatei HTTP. Dies hat den Vorteil, dass Sie nicht warten müssen, bis die gesamte Seite geladen ist, bevor das Protokoll in Visual Studio für Sie gerendert wird.

Auch - Sie können einige einfache Formatierung der Datei während des Streamings hinzufügen. Im Beispiel auf meinem Blog lasse ich einfach den Anfang jedes Ziels fett erscheinen, um sie etwas mehr hervorzuheben, aber Sie können sehen, wie Sie mit diesem Ansatz verrückt werden könnten, wenn Sie wollten.

+0

Danke Martin Ich hatte deinen Blogbeitrag schon einmal gesehen, konnte ihn aber nicht mehr finden. Danke für den Link. Ich denke, ich könnte das von Anfang an implementieren, damit ich die Logs zumindest schnell sehen kann. Ich habe auch ein paar Beiträge über das Hinzufügen von benutzerdefinierten Loggern gefunden, die ein guter Endpunkt sein könnten, Ihre aspx-Ansicht, die möglicherweise eine xsl-Transformation für eine benutzerdefinierte geloggte msbuild-Datei ausführt. http://blogs.msdn.com/aaronhallberg/archive/2006/08/30/adding-custom-loggers-to-team-build.aspx –

+0

Das wäre ziemlich cool. Wenn du den Code teilen möchtest, mit dem du gelandet bist, weiß ich, dass viele Leute daran interessiert wären - vielleicht sogar ein nettes kleines CodePlex-Projekt! –

1

Wenn die zunehmende Bandbreite keine Option ist, dann würde ich vorschlagen, dass Sie Ihren eigenen HTML-Logger schreiben und ihn an den Build-Prozess anhängen. Aufteilen des HTML-Build-Protokolls in kleinere Teile (definiert durch Ziele und/oder Projekte) und mit einer Indexdatei, die auf alle untergeordneten Teile mit geeigneten Informationen zeigt, ob ein gegebenes Teil fehlgeschlagen oder erfolgreich war. Dann müssen Sie nur die Indexdatei und alle angeforderten Teile über den Link analysieren.

Eine dritte Möglichkeit besteht darin, die Protokolldatei nach Abschluss des Builds zu komprimieren.

Verwandte Themen