Fehlersuche beim CCNetArtifactDirectory Problem in CruiseControl.net

Die Einrichtung eines automatisierten Build-Systems kann knifflig sein, insbesondere wenn es um plattformabhängige Konfigurationen geht. Eine häufige Herausforderung, mit der Entwickler konfrontiert sind, ist die Integration von CruiseControl.net mit der MSBuild-Aufgabe. Dieser Blogbeitrag zielt darauf ab, klarzustellen, wie Sie CCNetArtifactDirectory effektiv nutzen können, um sicherzustellen, dass Ihre Build-Ausgaben korrekt verwaltet werden, ohne unnötige Änderungen an den Projektdateien vornehmen zu müssen.

Das Problem verstehen

Möglicherweise sind Sie auf ein Problem gestoßen, während Sie CruiseControl.net einrichten, das die Konfiguration der MSBuild-Aufgabe betrifft. Die Hauptfrage hierbei ist:

Wie nutze ich CCNetArtifactDirectory effektiv innerhalb von MSBuild, ohne Fehler im Build-Prozess zu verursachen?

Die Verwirrung entsteht, weil CCNetArtifactDirectory zwar automatisch an MSBuild übergeben werden sollte, viele Benutzer jedoch feststellen, dass sie es in ihren Build-Argumenten nicht korrekt referenzieren können. Ein häufiger Fehler, den Sie möglicherweise sehen, ist:

ThoughtWorks.CruiseControl.Core.Config.Preprocessor.EvaluationException: Referenz auf unbekanntes Symbol CCNetArtifactDirectory

Lassen Sie uns in eine Lösung eintauchen.

Die Lösung

Keine Sorgen um CCNetArtifactDirectory

Die gute Nachricht ist, dass Sie CCNetArtifactDirectory nicht direkt in Ihren MSBuild-Befehlen angeben müssen. Standardmäßig übergibt CruiseControl.net dieses Verzeichnis an MSBuild, das sich darum kümmert, die Build-Ausgaben an dem richtigen Ort basierend auf dem in Ihrer Konfiguration angegebenen Arbeitsverzeichnis zu platzieren.

Hier ist ein Beispiel für eine Konfiguration:

<executable>c:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
<workingDirectory>C:\data\projects\FooSolution\</workingDirectory>
<projectFile>FooSolution.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug</buildArgs>

Speicherort der Ausgaben

Mit der obigen Konfiguration werden die Ausgaben Ihrer Builds an folgendem Ort geleitet:

C:\data\projects\FooSolution\[Projektname]\bin\Debug

Das bedeutet, dass die Artefakte korrekt generiert werden, ohne dass Sie sich um die Angabe von CCNetArtifactDirectory kümmern müssen.

Anpassen des Speicherorts der Ausgaben

Wenn Sie jedoch Ihre Ausgaben an einem anderen Ort ablegen möchten, können Sie dies durch den Abschnitt <publishers> in Ihrer CruiseControl.net-Konfiguration erreichen.

So passen Sie das Ausgabeverzeichnis an:

<publishers>
  <xmllogger />
  <buildpublisher>
    <sourceDir>C:\data\projects\FooSolution\FooProject\bin\Debug</sourceDir>
    <publishDir>C:\published\FooSolution\</publishDir>
    <useLabelSubDirectory>false</useLabelSubDirectory>
  </buildpublisher>
</publishers>

In dieser Beispielkonfiguration:

• sourceDir: Geben Sie das Verzeichnis an, aus dem MSBuild die Artefakte veröffentlicht.
• publishDir: Legen Sie das Ziel fest, an dem Sie die Build-Ausgaben veröffentlichen möchten.
• useLabelSubDirectory: Diese Option kann aktiviert oder deaktiviert werden, um Label-Verzeichnisse in Ihrem Veröffentlichungs-Pfad einzuschließen oder auszuschließen.

Zusammenfassung

Die Integration von CruiseControl.net mit MSBuild muss keine entmutigende Aufgabe sein. Indem Sie erkennen, dass Sie CCNetArtifactDirectory nicht direkt referenzieren müssen, können Sie Ihren Build-Prozess effektiv optimieren. Wenn Sie jemals die Build-Ausgaben umleiten müssen, konfigurieren Sie einfach den Abschnitt <publishers> entsprechend.

Mit diesen Lösungen sind Sie besser gerüstet, um Ihre automatisierten Build-Konfigurationen nahtlos zu verwalten.

Damit schließen wir unseren Überblick über den Umgang mit CCNetArtifactDirectory-Problemen in CruiseControl.net bei Verwendung von MSBuild ab. Nutzen Sie dieses Wissen, um Ihren Arbeitsablauf zu verbessern und Ihre Entwicklungserfahrung reibungsloser zu gestalten!