Eine neue Anwendung erstellen – Tutorial zu .NET

So, .NET ist jetzt auf unserem System installiert, und jetzt wollen wir damit einfach eine Reihe von Anwendungen erstellen mit verschiedensten Technologien. Wir haben das .NET-Kommandozeilentool und haben jetzt hier z.B. schon gesehen, dass es dotnet --info gibt, wo wir Informationen bekommen über alle installierten Runtimes und alle installierten SDKs. Bei mir sind es eine ganze Menge auf einem frisch aufgesetzten System möglicherweise deutlich weniger, etwa nur die 5.0.100 oder was auch immer Sie installiert haben. Außerdem kann ich nur dotnet aufrufen und dann bekomme ich die Information, was sonst noch unterstützt wird, etwa --list-sdks, dann kommen nur die SDKs oder --list-runtimes für nur die Runtimes. Oder eben Hilfe, also dotnet -h oder --help. Merke: Bei zwei Bindestrichen, bei zwei Minuszeichen immer der ausgeschriebene Befehl, und wenn es eine Kurzform gibt, dann die nur mit einem Minusstrich. Ja und jetzt sehen wir hier, es gibt eine Reihe von Befehlen, die wir verwenden können und einen Befehl haben wir schon mal kurz im Einsatz gesehen, nämlich new zum Erstellen einer neuen Applikation. Machen wir das doch mal. "Dotnet new" und nach einer erstmaligen Initialisierung bekommen wir jetzt eine ganze lange Liste von Anwendungstemplates. Eines davon hatten wir bereits im Einsatz, nämlich console und haben damit eine Konsolenanwendung erstellt, aber es gibt unter anderem auch wpf (Windows Presentation Foundation), also eine Windows-Oberflächenanwendung oder deren Vorgänger winforms. Ja, dann einiges für das Web. Man sieht also hier z.B. was mit MVC oder ASP.NET Core. Ja, wir sind also wieder bei dem Begriff Core, auch wenn hier der eigentlich so ein bisschen im Hintergrund verschwindet, teilweise auch unterstützt durch Frontend-Bibliotheken wie Angular oder React.js, APIs, ja und noch so einiges anderes mehr. Und was wir dann gesehen haben, ist, wenn wir sagen "dotnet new console", wird eine Konsolenanwendung erzeugt. Mit -o (o wie output) können wir auch einen Namen angeben, dann wird nämlich ein Unterordner angelegt, z.B. ConsoleApp1, schöner kreativer Name und dann gibt es eben diesen Ordner ConsoleApp1, und in diesem Ordner liegt dann eine Projektdatei csproj und die Programm.cs. Schauen wir uns zunächst die csproj, die Projektdatei an, die ist im XML-Format und enthält zwei wichtige Informationen hier, nämlich, na ja eigentlich drei. Welches SDK wird verwendet? Okay, es ist dotnet sdk von Microsoft. Na ja, was wollen wir am Ende haben? Eine exe? exe, das klingt jetzt schon wieder nach spezifisch für Windows, aber das haben wir vorher schon kurz gesehen, unter Linux und MacOS wurde auch noch eine Konsolenanwendung erstellt und auch da war der Output Type exe, aber halt eine exe auf Basis von .NET 5, die dann auch auf anderem Betriebssystem läuft, sofern die Runtime dort installiert ist. Und schließlich das Target Framework, welche Version von .NET steuern wir denn damit an. Und wir werden hier die aktuellste Installierte. Das ist .NET 5. Wollen wir Abwärtskompatibilität haben zur früheren .NET-Version, müsste man da eine niedrige Nummer eintragen, und es gibt auch teilweise Bemühungen, eine Art kleinsten gemeinsamen Nenner zu schaffen, aber wir bleiben jetzt einfach zunächst mal bei .NET 5. Diese Spezifika sind jetzt für uns nicht sonderlich interessant. Und wenn jetzt so eine Anwendung ausgeführt werden soll, wir können uns hier den Programmcode nochmal anschauen, ja also im Wesentlichen besteht die Anwendung aus einer Zeile, in der damit Text ausgegeben wird, dann sind drei Dinge notwendig. Zum einen dotnet restore. Wenn es nämlich Abhängigkeiten gibt, also irgendwelche Pakete, die das Projekt braucht, dann müssen diese erst entsprechend eingerichtet werden. Das geht jetzt hier relativ schnell und warum? Ich scrolle mal ein bisschen nach oben, als ich es vorher angelegt habe. Hier steht schon Running dotnet restore, d.h., wenn wir über das Template so eine Anwendung anlegen, dann wird dotnet restore automatisch ausgeführt. Klar, fügen Sie Abhängigkeiten hinzu, dann ist dotnet restore wieder notwendig. Und wenn das getan ist, können wir das ganze Ding kompilieren, also dotnet build, dann wird wieder dotnet restore gemacht, aber auch hier keine Änderung, gibt es nichts zu restoren, und jetzt wurde der Build-Vorgang erfolgreich ausgeführt. Sehen wir das irgendwo? Ja, wir haben einen neuen Ordner, nämlich den bin-Ordner, also schauen wir doch da mal rein. Dann gibt es Debug. Standardmäßig wird ein Debug-Modus kompiliert. Dann sehen wir den Ordner dotnet5.0. Hätten wir mehrere Ziele gehabt, also mehrere Ziel-Frameworkversionen, würden für all diese Ordner angelegt werden, und dadrin befindet sich jetzt tatsächlich unsere Konsolenanwendung, entsprechend noch dll und ein paar Konfigurationsinformationen. Das ist also das, was dann durch das Kompilieren erzeugt wird. Und jetzt gehe ich einmal wieder zurück ins Hauptverzeichnis. Ich könnte, klar, jetzt einfach die exe direkt aufrufen, aber letzter Befehl dotnet run. Was dotnet run macht, ist, der führt die Anwendung im Wesentlichen aus. Und so wird eine Anwendung angelegt, und das sind dann die Schritte, die passieren. In der Regel reicht auch dotnet run, weil wenn festgestellt wird, das wurde noch gar nicht kompiliert, also nicht gebuildet, wird intern dotnet build aufgerufen. Und wenn dotnet build feststellt, Oh, das sind irgendwelche Pakete, und nicht per dotnet restore eingerichtet wurden, dann wird auch nochmal intern dotnet restore aufgerufen. Und da das Ganze in einem Ordner stattgefunden hat, können wir diesen Ordner in Visual Studio einfach öffnen, hier ist er. Dann wird die Applikation geladen und kann dann eben direkt im Visual Studio Code weiterentwickelt und eben auch gestartet werden, wie üblich, wenn Assets fehlen, das ist im Wesentlichen ein Restore, dann fordert uns die IDE dazu auf, und dann wird alles korrekt eingerichtet. Im, in Anführungszeichen, großen Visual Studio könnten wir jetzt auch das Projekt öffnen. Würden wir eins neu erstellen wollen, dann und wir hatten das hier auch schon mal kurz gesehen, erhalten wir hier ebenfalls eine ausführliche Liste von Projektoptionen, sogar noch ein bisschen mehr als das dotnet-Kommandozeilentool selber unterstützt. Und damit alles, was wir uns anschauen, auch reproduzierbar ist für Sie, unabhängig davon, welche IDE Sie einsetzen, werden wir auch weiterhin die Projekte per Kommandozeile erzeugen und dann eben öffnen Sie die in der IDE Ihrer Wahl.