5 wesentliche .NET CLI-Befehle, die jeder Entwickler kennen sollte

Überprüfen Ihrer Umgebung mit dotnet --info

[0:31 - 1:25] Bevor er irgendwelche Projektbefehle ausführt, beginnt Tim damit, die Entwicklungsumgebung zu überprüfen. Der dotnet Befehl allein bestätigt, dass die CLI installiert und in Ihrem Pfad zugänglich ist, aber dotnet --info geht noch weiter:

dotnet --info

dotnet --info

Dies gibt jede auf Ihrem Rechner installierte SDK- und Laufzeitversion sowie die Details des Betriebssystems und der aktiven Architektur aus. Tim demonstriert dies an .NET 10, aber der Befehl funktioniert auf jeder Version identisch. Wissen, was Sie installiert haben, ist besonders hilfreich beim Debuggen von Versionsunterschieden oder um zu überprüfen, ob ein CI-Server Ihr lokales Setup widerspiegelt.

Befehl 1: dotnet build

[2:16 - 3:44] Der erste Befehl kompiliert Ihr Projekt, ohne es zu starten:

dotnet build

dotnet build

Das Ausführen dieses Befehls aus dem Projektverzeichnis liest die .csproj Datei, löst Abhängigkeiten auf und erzeugt kompilierten Output im bin Ordner. Tim weist darauf hin, dass die Kompilierung ein eigener, separater Schritt ist, getrennt von der Ausführung. Diese Trennung ist wichtig, wenn Sie sicherstellen möchten, dass Ihr Code sauber kompiliert, bevor Sie ihn in ein Repository schieben oder an einen Build-Server weitergeben.

Das .NET SDK handhabt die Abhängigkeitsauflösung während des Build-Prozesses, indem fehlende NuGet-Pakete gezogen werden und sichergestellt wird, dass alle referenzierten Assemblys vorhanden sind. Wenn in dieser Phase etwas fehlschlägt, weisen die Fehlermeldungen direkt auf das Problem hin, sei es ein fehlender Verweis, ein Syntaxfehler oder ein Zielrahmen-Mismatch. Diese Probleme vor dem Ausführen der Anwendung zu erkennen, spart Zeit im gesamten Entwicklungszyklus.

Befehl 2: dotnet run

[3:44 - 5:42] Wo build bei der Kompilierung stoppt, geht run den nächsten Schritt und startet die Anwendung:

dotnet run

dotnet run

Dies kompiliert das Projekt (falls erforderlich) und führt dann das resultierende Ergebnis aus. Für eine Konsolenanwendung bedeutet dies, dass sie im Terminal ausgeführt wird. Für ein Webprojekt startet der integrierte Kestrel-Server und die App ist unter einer lokalen URL verfügbar.

Tim demonstriert dies mit einer Webanwendung, indem er auf die laufende Seite in einem Browser navigiert, um zu bestätigen, dass alles korrekt geladen wird. Der wesentliche Unterschied zwischen build und run besteht darin, dass run ein Live-Ergebnis produziert, das interaktiv ist. Während der aktiven Entwicklung ist dies der Befehl, den Sie am häufigsten verwenden werden, um Änderungen zu testen und deren Auswirkungen zu sehen.

Befehl 3: dotnet watch

[5:42 - 7:06] Die Anwendung zu stoppen, eine Änderung vorzunehmen und sie neu zu starten, wird schnell mühsam. Der watch Befehl eliminiert diesen Zyklus:

dotnet watch

dotnet watch

Dieser umschließt den Ausführungsprozess in einem Dateiüberwacher. Wenn Sie eine Änderung an einer Quelldatei speichern, erkennt die CLI die Änderung und kompiliert und aktualisiert die Anwendung automatisch. Für mit ASP.NET Core erstellte Webanwendungen erscheinen Änderungen an Razor-Dateien, CSS und C#-Code im Browser, ohne dass ein manueller Neustart erforderlich ist.

Tim zeigt das Hot-Reload-Verhalten in Aktion: eine Seite bearbeiten, speichern und die Aktualisierung sofort sehen. Dieser enge Feedback-Zyklus ist wertvoll bei der Arbeit an der Benutzeroberfläche, wo ständig kleine Anpassungen erfolgen. Anstatt durch Stop-Bearbeiten-Neukompilieren-Starten zu gehen, bleiben Sie auf den Code konzentriert und lassen Sie die Werkzeuge den Rest erledigen.

Befehl 4: dotnet clean

[7:06 - 7:56] Build-Artefakte sammeln sich im Laufe der Zeit in den bin und obj Verzeichnissen an. Gelegentlich verursachen veraltete kompilierte Dateien verwirrendes Verhalten, bei dem Ihre neuesten Codeänderungen scheinbar nicht greifen oder eine lokale Build erfolgreich ist, aber auf einem frischen System fehlschlägt. Der clean Befehl behebt dies:

dotnet clean

dotnet clean

Während des Ausführens entfernt er den Inhalt der Ausgabeverzeichnisse, sodass Ihr nächster Build von Grund auf neu beginnt. Tim sieht dies als ein Werkzeug zur Fehlersuche an, anstatt etwas, das Sie nach jeder Änderung ausführen. Wenn Ihr Projekt unerwartet verhält und Sie ausgegeben Fehler im Cache vermuten, stellen clean gefolgt von build sicher, dass Sie mit einer wirklich frischen Kompilierung arbeiten.

Diese Gewohnheit ist besonders nützlich beim Wechseln von Branches in der Versionskontrolle, beim Aktualisieren einer Abhängigkeit auf eine neue Hauptversion oder beim Beheben von intermittierenden Build-Warnungen, die scheinbar ohne klare Ursache erscheinen und verschwinden.

Befehl 5: dotnet publish

[7:56 - 9:01] Der letzte Befehl schlägt die Brücke zwischen Entwicklung und Bereitstellung:

dotnet publish

dotnet publish

Während build eine Ausgabe erzeugt, die für lokales Debugging geeignet ist, erstellt publish ein einsatzbereites Paket. Die kompilierten Assemblies, Konfigurationsdateien, statischen Ressourcen und alle erforderlichen Laufzeitkomponenten landen in einem publish Ordner, den Sie direkt auf einen Server kopieren können.

Der Unterschied zwischen build und publish überrascht einige Entwickler. Der build Output enthält Debugging-Symbole und Referenzen, die während der Entwicklung nützlich, aber in der Produktion unnötig (und manchmal unerwünscht) sind. Das Veröffentlichen entfernt diese Extras und organisiert die Ausgabe für ihre Zielumgebung. Beim Bereitstellen in Docker oder Hochladen in eine Cloud-Hostingplattform ist die veröffentlichte Ausgabe das, was in Ihr endgültiges Image oder Release-Paket gehört.

Abschluss: Fünf Befehle, ein Workflow

[9:01 - 9:15] Tim schließt ab, indem er alle fünf zusammen listet: dotnet build, dotnet run, dotnet watch, dotnet clean und dotnet publish. Als Set betrachtet, decken sie die Kernentwicklungsroutine von der Kompilierung bis zur Bereitstellung ab. Jeder hat einen bestimmten Zweck, und wissen, wann man welchen verwenden sollte, gibt Ihnen ein Maß an Kontrolle, das Klicks in einer IDE allein nicht bieten können.

Abschluss

[9:15 - 9:30] Diese fünf CLI-Befehle behandeln die Aufgaben, die Sie am häufigsten während der Entwicklung ausführen: Kompilieren, Ausführen, Live-Reloading, Entfernen veralteter Ausgaben und Verpacken für die Veröffentlichung. Sie funktionieren über jeden .NET-Projekttyp und jedes Betriebssystem, das das SDK unterstützt.

Das nächste Mal, wenn Sie ein Terminal öffnen, sei es auf Ihrem lokalen Rechner, in einem Container oder auf einem entfernten Server, haben Sie das Vokabular, um ohne grafische Oberfläche durch den gesamten Entwicklungszyklus zu gehen.

Beispiel-Tipp: Sie können clean und build in eine einzelne Zeile mit dotnet clean && dotnet build verketten. Damit wird eine Kompilierung von Grund auf in einem Schritt garantiert, was besonders praktisch ist, wenn Sie Probleme beheben, die in inkrementellen Builds bestehen.

Sehen Sie das vollständige Video auf seinem YouTube-Kanal und erfahren Sie mehr über die .NET CLI Essentials.