In TeamCity habe ich eine Build-Konfiguration mit zwei msbuild-Build-Schritten erstellt, die eine Solution-.sln-Datei erstellen sollten.
Ich habe das Ziel als "Build" definiert, wenn ich den Build starte, führen beide Schritte offensichtlich die Standardkonfiguration aus und beide bauen entweder die Debug- oder die Release-Konfiguration zweimal auf.
Nun ging ich zu den Build-Einstellungen und fand das CommandLine Argument, für Debug fügte ich /p:Configuration=Debug hinzu, für Release fügte ich /p:Configuration=Release hinzu.
Dies erzeugt eine Warnung von TeamCity:
%Vor%Obwohl ein Debug und ein Release erstellt wurde.
Ich habe diese Nachricht gegooglet und zwei System Parameters : /p:Configuration=Debug und /p:Configuration=Release erstellt.
Wenn ich jetzt meine Kommandozeile für Debug auf %system.DebugConfig% und für Freigabe auf %system.ReleaseConfig% ändern würde, bekomme ich den gleichen Fehler.
Nur dann habe ich wirklich verstanden, dass diese Systemparameter niemals automatisch immer an jeden Build-Schritt übergeben werden.
Ok, aber wie definiere ich zwei verschiedene Build-Schritte, die das Debuggen und Freigeben mithilfe von Systemparametern oder ohne Team-City, die sich über /p in der Befehlszeile befindet, richtig definieren?
Es gibt keine Möglichkeit, dies zu tun (das weiß ich, ertragen Sie mit mir), aber es gibt genug Alternativen:
Wenn Sie bereit sind, separate Build-Schritte aufzugeben und stattdessen separate Builds zu verwenden - was normalerweise kein Problem sein sollte -, verwenden Sie Vorlagen: Erstellen Sie ein Build Template , in dem Sie alle Parameter hinzufügen, die konfigurierbar sein müssen, wie Configuration in Ihrem Fall und geben Sie ihnen geeignete Standardwerte. Erstellen Sie dann eine Build-Konfiguration für jede gewünschte Kombination von Eigenschaften, und überschreiben Sie in dieser Konfiguration die Parameter.
Eine andere Möglichkeit: Mach es selbst. Ich habe in der Vergangenheit zwischen ein paar CIs gewechselt und es wurde ziemlich offensichtlich, dass je mehr man sich auf die Funktionen eines CI-Systems verlässt, desto schwieriger wird es, Builds manuell zu testen, desto lästiger wird es durch die Web-Schnittstellen des CI-Systems oder Datenbanken oder Konfigurationsdateien, um die richtigen Konfigurationsparameter zu finden, und je krasser der Übergang zu einem anderen CI wird. An einem bestimmten Punkt gab ich es einfach auf und schrieb ein paar msbuild 'master'-Skripte, die alles mit einem Klick auf die Schaltfläche erstellen würden, sozusagen, erinnere dich an die Joel Test , aber auf jeder Maschine, die ich will, einschließlich meiner eigenen, ohne die Notwendigkeit für irgendeine CI überhaupt. Das war so eine Erleichterung, dass ich seitdem nicht mehr zurückblicke, und die CI-Konfiguration ist jetzt auf ein Minimum beschränkt. Angewandt auf Ihren Fall: Erstellen Sie eine Msbuild-Datei wie unten und einen Build-Schritt in TC, der das Build-Ziel aufruft und einen MyTargetProjectFile-Systemparameter hat, der auf die eigentliche Projektdatei verweist:
%Vor%Noch eine weitere Option: ignorieren Sie einfach die Warnung von TeamCity. Es war mir nie klar, warum sie darauf bestehen, es scheint nicht eingängig zu sein und führt zu Fragen wie dieser:] Verschiedene Bauformen mit unterschiedlichen Eigenschaften zu haben, scheint eine ziemlich grundlegende Anforderung zu sein, nein? Ich denke nicht, dass wir einen Msbuild-Schritt haben, der / p nicht verwendet, und alles funktioniert gut.