Visual Studio 2017

Visual Studio 2017

Kurz vorweg: Dieser Blog Post ist Teil einer Serie und setzt auf die früheren Teile auf. Lest bitte alle Teile, damit ihr nichts wichtiges verpasst. Zu finden sind alle Beiträge unter dem Tag VS2017.

Cross-Platform Entwicklung

Jetzt mal nur den PC / Laptop Markt im Blick, es gibt ja nicht nur Windows. Apples MacOS wird immer bekannter, woran Microsoft selbst Schuld ist, aber auch Linux wird immer bekannter, nicht zuletzt durch Kleinsysteme wie dem Raspberry Pi. Auf mobile Entwicklung, also Android und iOS, gehe ich hier nicht ein, ich habe keins dieser Geräte. Windows Phone ist der Erwähnung nicht wert, das Ende des Supports steht schon fest. Habt ihr schön gegen die Wand gefahren, Microsoft! Aber heute soll es nicht um die unzähligen Fehlentscheidungen aus Redmond gehen.

Heute arbeiten wir wieder an unserem Projekt aus dem 2. Teil. Nicht gelesen? Blöd. ^^

Vorab

Dieser Teil wird wiederum ein Mehrteiler. Es wird an manchen Stellen etwas komplex, und auch um die Konsole / Eingabeaufforderung werdet ihr leider nicht drum herum kommen. Alles in allem ist das aber nicht schlimm. Ich gliedere es in diese Punkte auf:

  • 3a) Programmierung
    Darum geht es in diesem Teil.
  • 3b) Kompilierung
    Hier wird es um die Kompilierung und um das "Publish" gehen, also das erstellen der fertigen Kompilate (bei Windows den .exe Dateien).
  • 3c) Veröffentlichung
    Das automatische verpacken in die für das System optimalen Formate.

Und ab geht's.

Programmierung

Prinzipiell sind wir schon recht gut vorbereitet. Erinnert ihr euch noch daran dass ich die Projektmappe "BlogExample" und das Projekt "BlogExample_FW" genannt habe? Gleich wisst ihr warum.

Wenn man von vorn herein auf Cross-Platform zielt, wäre es besser mit einer .Net Core Konsolenanwendung zu starten, statt einer regulären .Net Framework Anwendung. .Net Core ist hier und da ziemlich limitiert, was aber kein Problem ist, wenn man es weiß. So würdet ihr auf jeden Fall beim Programmieren sofort sehen, ok, das geht so nicht. Aber, viele Wege führen nach Rom.

Zu den gravierendsten Nachteilen für .Net Core zählen wohl: Keine interne Unterstützung für GUI (Windows Forms oder was auch immer) und - zumindest für mich - kein SerialPort. Aber dazu später. Viel später. Ich hab's nämlich noch nicht hin bekommen…

Unsere Testanwendung betrifft das jetzt aber nicht, ist ja auch nichts spezielles.

Wirklich programmieren brauchen wir hier eigentlich gar nichts, wir können den selben Code also 2x nutzen, für die Framework und die Core Version. Wer jetzt aber an Copy-Paste denkt… Gehen würde es natürlich. Gut wäre es aber nicht. Daher schrauben wir erst etwas am Projekt rum.

Das Projekt bearbeiten

Als Erstes räumen wir etwas auf. Standardmäßig werden mehrere Dateien erstellt, die nicht benötigt werden. 

Klickt im Projektmappen-Explorer erst auf "Alle Dateien anzeigen" und löscht dann diese 3 ausgewählten Dateien (sofern vorhanden). Nur die AssemblyInfo.vb / .cs wird benötigt, und natürlich unsere App.vb / .cs.

Als nächstes schließen wir das Visual Studio kurzzeitig. Geht im Datei Explorer in den Projektordner und erstellt ein neues Verzeichnis, ich nenne es immer gerne "SharedSource". Verschiebt die App.vb aus \BlogExample_FW\App.vb in \SharedSource\App.vb.

Startet Visual Studio erneut, öffnet das Projekt. Natürlich findet er die Datei jetzt nicht mehr.

Diese löschen wir jetzt. Danach klickt mit rechts auf die Projektmappe - "Hinzufügen" - "Neuer Projektmappenordner…". Benennt ihn wie den Ordner den wir erstellt haben, also "SharedSource". Klickt hierauf auch mit rechts, "Hinzufügen", "Vorhandenes Element…". Dort wählt ihr die App.vb aus. Ist streng genommen zwar nicht nötig, aber stark von Vorteil.

Jetzt brauchen wir die App.vb aber wieder in unserem Projekt. Klickt also mit rechts auf das Projekt - Hinzufügen - Vorhandenes Element. Wählt hier die App.vb aus, aber: Klickt nicht gleich auf Hinzufügen oder die Datei selbst, sondern markiert nur die Datei und klickt auf den Pfeil direkt daneben und wählt "Als Link hinzufügen" aus!

Danach sollte es so aussehen:

Hier sieht man an dem kleinen Icon dass die Datei App.vb nicht mehr wie vorher direkt im Projekt drin ist sondern nur verlinkt ist.

Vorbereitet ist jetzt alles, jetzt geht es weiter.

Ein neues Projekt erstellen

Macht also einen Rechtsklick auf die Projektmappe, Hinzufügen, Neues Projekt. Wir erstellen wieder eine Konsolenanwendung, dieses mal aber als .Net Core.

Diese nennen wir BlogExample_Core (statt _FW).

Die erstellte Program.vb brauchen wir nicht, weg damit. Wir fügen wieder unsere App.vb aus \SharedSource hinzu, natürlich wieder als Link, wie grade eben.

Sieht denn so aus:

Der Sinn hinter dem ganzen ist einfach. Wir haben jetzt 2 Projekte, eins für das reguläre .Net Framework, welches schon auf allen gängigen Windows Systemen vorinstalliert ist, und eine für das .Net Core, was leider noch nicht so verbreitet ist, aber dafür Cross-Platform-fähig ist. Jetzt wisst ihr auch warum das mit _FW und _Core. ;)

In den Projekteigenschaften (von beiden) könnt ihr natürlich noch Einstellungen anpassen, wie den Assemblynamen. Hier kann das Anhängsel natürlich entfernt werden. Copyright Informationen und so weiter, aber das ist ja schon seit zig Jahren Standard.

Für uns jetzt nicht benötigt, aber kann man mal im Hinterkopf behalten: Nicht nur SharedSource erstellen, sondern auch SharedResources, sowohl den Ordner als auch den Projektmappenordner. Der wäre denn für Bilder und sonstige angehängte Dateien (Lokalisierungsdaten, Dokumente wie Lizenzen, …).

Sehr nett hierbei (und das hätte ich nie gedacht), wenn ihr beide Projekte drin habt und am Programmieren seid, bekommt ihr per Intellisense gleich angezeigt wenn ein Projekt diesen Code nicht unterstützt:

And the beat goes on

Aber erst in Teil 3b. Behaltet den Tag VS2017 im Auge.