ich mit ContinueOnError = true die MSBuild Aufgabe leite:Wie kann man überprüfen, ob eine MSBuild-Aufgabe schlägt fehl, wenn mit ContinueOnError = true
<MSBuild Projects="@(ComponentToDeploy)"
Targets="$(DeploymentTargets)"
Properties="$(CommonProperties);%(AdditionalProperties)"
ContinueOnError="true"
Condition="%(Condition)"/>
Also meine Build gelingt es immer wieder.
Gibt es eine Möglichkeit herauszufinden, ob ein Fehler auftritt?
Ich konnte keinen Output der MSBuild Aufgabe mit diesen Informationen finden. Die einzige Möglichkeit, die ich weiß, ist die Protokolldatei für Fehler zu analysieren, aber es sieht wie eine Umgehung für mich aus.
(Ich bin mit MSBuild 4,0)
Dies ist eine Antwort auf das letzte Feedback von @Ilya.
Ich verwende Feedback/Antwort wegen der Länge und Formatierungseinschränkungen der Kommentare.
Log auf individuelle Ziele scoped oder mehrere spezifische Aufgaben zu sein ...
Dies war in der Tat die erste Frage stellt sich, als ich Ihren Kommentar mit dem Vorschlag zu lesen Log.HasLoggedErrors
zu verwenden: "Was ist der Umfang des Logs? ".
Leider konnte ich keine richtige Dokumentation finden. MSND hilft nicht viel ...
Warum wussten Sie, dass es auf die Aufgabe beschränkt ist?
Ich zweifle nicht an Ihrer Aussage überhaupt! Ich frage mich nur, wenn es eine richtige Dokumentation irgendwo .. (ich habe nicht MSBuild seit Jahren ;-)
In jedem Fall gewesen verwenden, was Sie als Projekt Bau ?
Meine Testprojekte sind sehr einfach.
MyTest.project
<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="ElenasTarget" ToolsVersion="4.0">
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\MyCompany.Tools.MSBuild.Tasks.dll" TaskName="MSBuildWithHasLoggedErrors" />
<ItemGroup>
<MyProjects Include="CopyNotExistingFile.proj" />
</ItemGroup>
<Target Name="ElenasTarget">
<MSBuildWithHasLoggedErrors Projects="@(MyProjects)" ContinueOnError="true" >
<Output TaskParameter="HasLoggedErrors" PropertyName="BuildFailed" />
</MSBuildWithHasLoggedErrors>
<Message Text="BuildFailed=$(BuildFailed)" />
</Target>
</Project>
Die CopyNotExistingFile.proj versucht, nur eine Datei zu kopieren, das nicht existiert:
<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Target1" ToolsVersion="4.0">
<Target Name="Target1">
<Copy SourceFiles="C:\lalala.bum" DestinationFiles="C:\tralala.bam" />
</Target>
</Project>
Und das ist meine benutzerdefinierte Aufgabe MSBuildWithHasLoggedErrors
namespace MyCompany.Tools.MSBuild.Tasks
{
public class MSBuildWithHasLoggedErrors : Microsoft.Build.Tasks.MSBuild
{
[Output]
public bool HasLoggedErrors { get; private set; }
public override bool Execute()
{
try
{
base.Execute();
HasLoggedErrors = Log.HasLoggedErrors;
}
catch (Exception e)
{
Log.LogErrorFromException(e, true);
return false;
}
return true;
}
}
}
Wenn ich MyTest.proj erstelle, wird HasLoggedErrors
auf false
gesetzt, obwohl ein Fehler (MSB3021) protokolliert wurde (?) An die Konsole Logger:
Project "C:\Users\elena\mytest.proj" on node 1 (default targets).
Project "C:\Users\elena\mytest.proj" (1) is building "C:\Users\elena\CopyNotExistingFile.proj" (2) on node 1 (default targets).
Target1:
Copying file from "C:\lalala.bum" to "C:\tralala.bam".
C:\Users\elena\CopyNotExistingFile.proj(5,4): error MSB3021: Unable to copy file "C:\lalala.bum" to "C:\tralala.bam". Could not find file 'C:\lalala.bum'.
Done Building Project "C:\Users\elena\CopyNotExistingFile.proj" (default targets) -- FAILED.
ElenasTarget:
BuildFailed=False
Done Building Project "C:\Users\elena\mytest.proj" (default targets).
Build succeeded.
Meine Erwartung wurde HasLoggedErrors
würde true
eingestellt werden.
ein Weg ist, mich selbst zu bauen, aber mit unterschiedlichem Ziel, zum Beispiel Ihrer Default ein startet Ihre benutzerdefinierte MSBuildWrapper Aufgabe selbst zeigt (dh $ (MSBuildProjectFile)), aber mit einem anderen Ziel, dass macht andere Builds, Kopien
Ich habe es bereits versucht (das waren meine Untersuchungen, die ich in meinem Post meinte). Leider ist es nicht funktionieren :-(
(Ich bin mir bewusst gesagt, du in Theorie) Mein neues einzigen Projekt sieht wie folgt aus:.
<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="ElenasTarget" ToolsVersion="4.0">
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\MyCompany.Tools.MSBuild.Tasks.dll" TaskName="MSBuildWithHasLoggedErrors" />
<Target Name="ElenasTarget">
<MSBuildWithHasLoggedErrors Projects="$(MSBuildProjectFile)" Targets="CopyNotExistingFile" ContinueOnError="true" >
<Output TaskParameter="HasLoggedErrors" PropertyName="BuildFailed" />
</MSBuildWithHasLoggedErrors>
<Message Text="BuildFailed=$(BuildFailed)" />
</Target>
<Target Name="CopyNotExistingFile" >
<Copy SourceFiles="C:\lalala.bum" DestinationFiles="C:\tralala.bam" />
</Target>
</Project>
Wenn ich dieses Projekt HasLoggedErrors
bauen nach wie vor eingestellt werden, um false
.
(Des Weiteren meine „echte“ Build ich zur Zeit beibehalten viel komplexeren mehrere Projektdateien mit Zielen enthalten ... so kann ich sie nicht packen alle in einem einzigen Projekt-Datei).
oder benutzerdefinierte Logger zu schreiben und es durch Zeilenbefehl vorbei
Das ist meine letzte Hoffnung war!
Meine "echte" Build hat eine benutzerdefinierte Logger über die Befehlszeile (ich habe es nicht für meine Test-Projekt der Einfachheit halber verwendet). Das erzeugt tatsächlich das Protokoll (eine XML-Datei), die ich analysieren werde, um herauszufinden, ob irgendwelche Fehler protokolliert wurden.
BTW, ich dachte der Konsolenlogger ist eine Art "globaler" Logger. Bin ich falsch?
Wie auch immer, der benutzerdefinierte Logger hilft auch nicht, der Log.HasLoggedErrors
ist immer noch auf false
eingestellt.
Gibt es eine Möglichkeit, dass ich nicht auf einen bestimmten Logger (z. B. meine benutzerdefinierte Logger) zu fragen, um zu fragen, ob es irgendwelche Fehler protokolliert hat?
Es sieht wirklich so aus Log
ist auf einzelne Ziele beschränkt.
Hmm ... wenn die Reflexion über die Gebäude-Instanz der letzte Ausweg ist, würde ich immer noch lieber das Protokoll analysieren.
(Do not blame me :-)!)
Meine Entscheidung
Nach einigen Untersuchungen habe ich beschlossen, mit meiner ersten Lösung zu bleiben: analysieren Sie das Protokoll, um herauszufinden, ob die Build fehlgeschlagen .
Überprüfen Sie meine Kommentare, um zu sehen, warum ich es vorziehe, dass die Vorschläge bisher bereitgestellt wurden.
Wenn jemand hat einige andere Ideen, zögern Sie nicht :-) zu teilen
(Ansonsten kann diese Frage geschlossen werden, nehme ich an ...)
+1 für den Hinweis auf eine neue reservierte Eigenschaft, die auf der MSDN-Site noch fehlt! Ich war mir dessen nicht bewusst. Das ist die Lösung, nach der ich gesucht habe, danke! – Elena
Wenn Sie unten auf der Seite mit den reservierten MSDN-Eigenschaften nachsehen, sehen Sie, dass jemand aus der Community einige fehlende Eigenschaften freundlicherweise dokumentiert hat. Rätselhaft, dass die offizielle Dokumentation noch nie aktualisiert wurde. –
Ja, ich habe diesen Kommentar gerade heute gelesen und ich habe sogar die letzte Ausgabe des Buches von Sayed Ibrahim Hashimi auf meinem Tisch ;-) aber ich war mir dieser Eigenschaft nicht bewusst, thx wieder! – Elena