Weiß MSBuild, ob ein Projekt neu kompiliert werden muss?

Question

Zunächst habe ich eine Grundannahme von Visual Studio Kompilieren von Dingen mit seinen Standard. * Proj-Dateien, die, wenn Sie die gleiche Lösung zweimal hintereinander erstellen, erkennt, dass nichts geändert hat und scheint durch die Lösung Build zu fliegen. Bedeutet dies, dass nichts in einem Projekt geändert wurde und keine neue DLL-Ausgabe erstellt werden muss?

Wenn das der Fall ist, habe ich eine Frage. Angenommen, ich habe eine Lösung mit mehreren Klassenbibliotheken und einer MSBuild-Task in jedem Projekt, die die Version des Builds automatisch erhöht, indem AssemblyInfo.cs geändert wird. Ding ist (wenn meine vorherige Annahme richtig ist) es tut dies jedes Mal und löst eine neue Rekonstruktion jeder Klassenbibliothek aus. Gibt es in MSBuild ein Ziel oder eine Eigenschaft, die feststellen kann, ob das Projekt neu kompiliert werden muss, und wenn ja, wie kann ich meinen Versionsschritt überspringen?

Ich frage, weil ich sagen, ich aktualisiere Projekt A, aber nicht Projekt B in einer Lösung. Wenn ich einen Build für die Lösung ausführe, möchte ich, dass die Version in Projekt A aktualisiert wird, aber da sich Projekt B nicht geändert hat, möchte ich es in Ruhe lassen.

Answer 1

Etwas gefunden: http://msdn.microsoft.com/en-us/library/ms171483.aspx

MSBuild die Zeitstempel von der Eingabedateien mit dem Zeitstempel von der Ausgabedateien vergleichen und festzustellen, ob zu überspringen, bauen oder teilweise wieder aufzubauen ein Ziel. Wenn im Beispiel eine Datei in der @ (CSFile) -Einheit Sammlung neuer ist als die Datei hello.exe , wird MSBuild das Ziel ausführen; sonst wird es übersprungen werden:

<Csc 
    Sources="@(CSFile)" 
    OutputAssembly="hello.exe"/> </Target> 

... das funktionierte. Aber dann habe ich darüber nachgedacht, was passiert, wenn jemand den Code ohne die Assemblies aus der Quellcodeverwaltung abzieht (wie machen wir das)? Da es keine Ausgabe zum Vergleichen gibt, wird die Version trotzdem kompiliert und inkrementiert. Ich denke, die Komplexität könnte mich dazu bringen, diesen Ansatz aufzugeben.

Answer 2

Es spielt keine Rolle, ob Sie eine Entwicklerbox inkrementieren - wichtig ist, dass Ihr tägliches/CI-Build nur bei Bedarf inkrementiert wird. Was ich in der Vergangenheit getan habe, ist, dass eine kleine XML-Datei die nächste Build-Nummer enthält und eine MSBuild-Aufgabe diese XML-Datei nimmt und eine Datei namens Version.cs (mit den Versionsattributen, in der Regel zu finden) erstellt AssemblyInfo.cs).

Version.cs wird nie in Ihre eigene Kontrolle eingecheckt - es wird durch den Build generiert.

Entwickler werden die aktuelle XML-Datei synchronisieren, ihre Binärdateien erstellen und die aktuelle Versionsnummer abrufen. Die kontinuierliche Integration Build kann auch das gleiche tun. Aber ein täglicher/offizieller Build wird die XML-Datei auschecken, die Versionsinformationen inkrementieren und dann einchecken. Ab diesem Zeitpunkt hat sich die Versionsnummer offiziell geändert.

Es gibt Variationen zu diesem Thema, aber die allgemeine Idee funktioniert.