Was sind MSbuild-Aufgaben und in welchen Situationen sollten Sie sie verwenden oder nicht verwenden? Was sind die Alternativen? Welche Vorteile oder Nachteile bieten sie?Was sind MSbuild-Aufgaben und wann und warum würden Sie sie verwenden?
Eine Task implementiert die Task class und kann als solche von msbuild code aufgerufen werden. Normalerweise wird dies z.B. Schreiben eines C# -Codes, der die Klasse implementiert und sie in eine DLL integriert, die an das UsingTask-Element übergeben wird, um es verfügbar zu machen. Es gibt auch einen kürzeren Weg, dies zu tun: mit Inline Tasks. Dies ermöglicht das direkte Schreiben des Codes in die Msbuild-Datei.
Eigentlich gibt es keine Alternative, da eine Task die oben angegebene Definition hat und es nur eine solche Sache mit genau diesen Eigenschaften in msbuild gibt. Es gibt auch eine Target, die verwendet wird, um Tasks aufzurufen (und eine Reihe anderer Funktionen wie das Ausdrücken von Abhängigkeiten zu anderen Zielen, das Definieren von Ein/Ausgängen, ...). Es ist also eine Alternative, wenn man bedenkt, dass es Überschneidungen gibt, und ich nehme an, dass Sie das wollen: Sie können Funktionen erstellen, indem Sie mehrere Aufgaben nacheinander in einem Ziel aufrufen (oder Ziele von anderen Zielen abhängig machen) oder indem Sie Ihre schreiben eigene Aufgabe, die alle oder einige dieser Aktionen ausführt.
Beispiel: Angenommen, Sie möchten ein Verzeichnis auflisten und alle .c-Dateien in ein anderes Verzeichnis kopieren und dann das Verzeichnis komprimieren. Entweder Sie schreiben ein Ziel, in dem Sie die Dateien auflisten (mit einer ItemGroup), und dann rufen Sie die Aufgaben Kopieren und Zip auf. Oder Sie schreiben eine benutzerdefinierte Aufgabe, die C# -Aufrufe wie Directory.GetFiles/File.Copy/ZipFile.CreateDirectory verwendet und den Zielanruf nur Ihre benutzerdefinierte Aufgabe hat.
Vorteile von benutzerdefinierten Aufgaben: Sie können beliebigen Code enthalten, so können Sie im Grunde tun alles können Sie sich vorstellen. Nachteil: muss mit dem Msbuild-Code erstellt, gewartet und ausgeliefert werden (entweder als DLL oder als Quellcode, in diesem Fall müssen sie im laufenden Betrieb erstellt werden, bevor sie verwendet werden können).
Vorteile von Zielen mit vorhandenen (eingebauten) Aufgaben: Die gängigste Funktionalität in Build-Systemen ist in bewährter Code mit reichlich Dokumentation und/oder SO Fragen als zusätzliche Ressourcen, keine Neuerfindung von Rädern, andere wissen dieser Code auch schon, keine Pflege von benutzerdefiniertem Code. Nachteil: Nicht jede einzelne Funktionalität ist verfügbar, die Anzahl der zusammengesetzten Aufgaben zur Erreichung der Funktionalität ist möglicherweise zu hoch oder unpraktisch.
Die Verwendung von Aufgaben wird grundsätzlich durch die beiden obigen Absätze beantwortet. Ich kann Ihnen unmöglich sagen, wie viele benutzerdefinierte Aufgaben Sie in der Praxis schreiben werden, da ich Ihre Anwendungsfälle nicht kenne. Betrachtet man den gesamten msbuild-Code, den ich selbst habe (um mit einer Mischung aus C/C++/C#/Python-Projekten umzugehen), würde ich sagen, dass es zu 95% integrierte Aufgaben und 5% benutzerdefinierte Aufgaben sind. Von diesen 5% stammen die meisten von Aufgaben, die von anderen Ike MSBuild Community Tasks und MSBuild Extension Pack geschrieben wurden.