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.


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.

Git

Heute soll es um Git gehen. Aber vorweg möchte ich noch etwas erwähnen. Es bringt absolut nichts, wenn ihr eure Quelltexte, die Git Repositories etc., an einem unsicheren Speicherort (wie Laufwerk C:) lagert. Sorgt lieber erst mal für Datensicherheit. Wie das geht habe ich bereits hier beschrieben: Darf's noch etwas sicherer sein?

Was ist Git?

Kurz vorweg ein paar Begriffserklärungen.

  • Repository
    Das ist das eigentliche Arbeitsverzeichnis von Git, wenn man so möchte. Hier liegt das Projekt drin, inklusive allen Vorgängerversionen, Branches, … normalerweise ohne Kompilate, also den fertigen Binärdateien (.exe) oder Releases (MeineApp.zip).
  • Pull
    Hiermit "zieht" man sich die aktuelle Version (oder die explizit angegebene) aus dem Repository heraus, ähnlich wie ein Download des Quelltextes von einer Webseite. Wird auch manchmal "Auschecken" genannt, auch wenn das hier nicht so ganz zutrifft.
  • Push
    Wer hätte es gedacht, das Gegenteil von Pull. Hiermit werden die Änderungen die man in seiner lokalen Arbeitskopie gemacht hat übertragen. Wird auch öfters "Einchecken" oder "Commit" genannt.
  • Sync
    Hierbei wird das lokale Repository mit einem Remote Repository abgeglichen, sprich Änderungen die ihr gemacht habt werden hoch geladen, Änderungen die ihr noch nicht habt werden heruntergeladen.
  • Branch
    Eine Verzweigung. Dies kann man sich ungefähr so vorstellen, Debian Linux ist der Master, der Ursprung (origin). Raspbian, Ubuntu, … basieren auf Debian, haben aber eine Andere Zusammenstellung, sind also ein Branch von Debian. Wie man das jetzt genau nutzt bleibt einem natürlich selbst überlassen.

Git ist eine Versionskontrolle. Gehen wir jetzt mal davon aus dass ihr nur alleine entwickelt. Irgendwann fangt ihr mit einem Projekt an, testet es, zumindest in Teilen, und befindet es für ok, also lauffähig. Dann könnt ihr eure Änderungen in Git pushen, wohlgemerkt mit einer Notiz was ihr warum geändert habt. Merkt ihr später dass ihr euch verrannt habt und eure Änderungen so doch nicht umsetzbar sind könnt ihr immer wieder zu Zeitpunkt X zurück kehren, natürlich vorausgesetzt dass ihr vorher auch eingecheckt habt.

Jetzt gibt es ein lokales Git Repository, aber vielleicht auch ein Remote Repository. In meinem Fall wäre das git.tightDev.Net. Das ist zwar optional, aber benötigt, wenn man mit mehreren Leuten gleichzeitig an einem Projekt arbeiten möchte. Es muss nicht unbedingt ein über das Web erreichbarer Server sein, es kann auch auf das Firmennetzwerk limitiert sein.

Es sei aber noch gesagt dass Git ein gewaltiges Thema werden kann, ich kratze hier nur an der Oberfläche und ich weiß auch noch nicht alles.

Vorbereitung

Erstellt jetzt ein leeres Verzeichnis wo eure Projekte drin liegen sollen, z.B. S:\Git falls ihr meinen Rat von oben befolgt habt. Ich gehe davon aus dass ihr Git bereits installiert habt (belasst alles bei den Standardeinstellungen).

Schnellstart

Ab jetzt gibt es 2 Wege. Ein neues Projekt erstellen oder ein existierendes öffnen.

Ein existierendes Projekt öffnen

Könnte man jetzt umständlich über die Konsole machen (git clone), aber man kann auch einfach vom Git Server die Kopie herunterladen. Diese entpackt ihr dann in S:\Git\Projektname. Danach einfach die Projektdatei öffnen.

Ein neues Projekt erstellen

Ich erstelle hier jetzt mit Absicht eine .Net Konsolenanwendung. Das liegt daran weil ich später noch auf Cross-Platform Entwicklung mit .Net Core eingehen möchte (dort ist leider noch keine GUI unterstützt, zumindest nicht von Haus aus). Mit der Konsole selbst kann man aber auch schon einiges machen. ;)

Als Name habe ich jetzt bewusst BlogExample_FW genommen, es ist eine .Net Framework Anwendung. Das _FW habe ich aus dem Projektmappennamen wieder raus genommen. Warum? Dazu kommen wir später, wenn es um Cross-Platform geht. Ich nutze hier VB.Net, aber ihr könnt es genau so auch mit C# machen, falls euch die Sprache eher liegt.

Wichtig ist hier noch unten rechts "Neues Git-Repository erstellen", der muss aktiviert sein.

Interessant wird es jetzt unten rechts:

Links zeigt an wie viele Änderungen noch an ein Remote Repository übertragen werden müssen (wenn man es nutzt). 2 ist hier ganz normal, es handelt sich hierbei um die Dateien .gitattributes und .gitignore (normalerweise versteckt). Diese konfigurieren Git, so dass z. B. bestimmte Dateien nicht synchronisiert werden. Die Attribute lassen wir so wie sie sind, aber die .gitignore sollten wir jetzt mal kurz im Notepad (o. Ä.) öffnen. Hier fügt ihr oben die folgenden Zeilen ein:

*.plb
Thumbs.db
.DS_Store

.plb Dateien werden von Photoline automatisch erstellt, Thumbs.db von Windows. Es handelt sich hier um Miniaturansichten der Grafiken. Braucht kein Mensch, muss nicht synchronisiert werden. .DS_Store erstellt MacOS auf jedem Laufwerk und in jedem Verzeichnis was es in die Finger bekommt. Nutzen bei allen gleich 0, also weg damit.

Zurück in's VS. Der Punkt rechts daneben (im Screenshot 0) zeigt die Änderungen an (veränderte, hinzugefügte und gelöschte Dateien).

Ein weiter öffnet den Team Explorer. Und zu guter Letzt könnt ihr den Branch auswählen oder einen Neuen erstellen. Ganz so tief gehe ich hier aber nicht in's Detail.

Der erste Quelltext

Im Projektmappenexplorer seht ihr jetzt dass eine Module1.vb erstellt wurde. Diese habe ich in App.vb umbenannt (mache ich immer so) und in ihr diesen Quelltext eingefügt:

''' <summary>Module containing all application related stuff.</summary>
Friend Module App

	''' <summary>Application main entry point.</summary>
	Friend Sub Main()

		' Ask for user name
		Console.Write("Enter your name: ")
		Dim sName As String = Console.ReadLine

		' Greet the user
		Console.WriteLine()
		Console.WriteLine("Hello, " & sName & ".")

		' Wait before exit
		Console.WriteLine()
		Console.WriteLine("Press any key to exit...")
		Console.ReadKey(True)

	End Sub

End Module

Der Quelltext ist eigentlich selbsterklärend, absolut nichts spezielles. Beachtet aber, dass ich vorher mit 3fach Kommentaren (''' in VB.Net, /// in C#) über dem Modul und der Sub spezielle Kommentare angelegt habe. Gewöhnt euch das gleich an, das wird später noch wichtig wenn wir zur Dokumentation kommen. Das <summary> und ggf. weitere Felder erstellt Visual Studio dann automatisch selbst.

Jetzt steht unten rechts auch dass wir 3 Änderungen im Projekt vorgenommen haben.

Klickt man hierauf sieht man diese.

"Module1.vb" wurde gelöscht, "App.vb" hinzugefügt. Technisch jetzt zwar nicht ganz so richtig, wir haben sie ja nur umbenannt, aber passt schon. Und natürlich wurde auch die Projektdatei bearbeitet.

Was jetzt zwingend noch gemacht werden muss ist oben im gelben Feld einzugeben was man seit dem letzten Commit bearbeitet hat. Da dies unser erster Commit ist können wir hier "Initial commit." eingeben, sonst natürlich eine Auflistung der Änderungen die wir gemacht haben.

Danach auf "Commit für alle" klicken und das lokale Git Repository wird aktualisiert.

Das erste "Whoops"

Machen wir jetzt nicht, aber nur rein theoretisch. Klickt unten rechts auf master (oder wie euer Branch heißt). Dort könnt ihr euch die Änderungen anzeigen lassen. In dem Verlauffenster seht ihr jede übertragene Änderung (jedes Commit) und könnt entweder die alte Version einer Datei öffnen (Doppelklick auf den Commit, die Dateien erscheinen dann im Team Explorer) oder komplett zum ausgewählten Commit zurück kehren.

Die Cloud

Welcher Vollhorst hat sich den Begriff überhaupt ausgedacht? Naja, Internet ist halt #Neuland… Es soll jetzt um ein Remote Repository gehen. Der kann im Netzwerk stehen aber auch über das Internet erreichbar sein.

Wie auch immer, ihr bekommt eine Git URL, wie https://git.tightdev.net/BlogExample.git. Abgesehen davon habt ihr natürlich eure Anmeldedaten. Jetzt muss das Ganze nur noch verlinkt werden.

Klickt hierzu unten rechts auf den Linken Button mit dem Pfeil hoch, danach auf "Git-Repository veröffentlichen". Dort fügt ihr die URL ein, danach Klick auf "Veröffentlichen".

Ihr werdet dann ggf. noch nach euren Anmeldedaten gefragt. Sollte ein Name für das Repository abgefragt werden benennt es auf jeden Fall "origin". Normalerweise wird das aber standardmäßig gesetzt. Mag sich ändern wenn es verschiedene Branches gibt, aber so weit sind wir noch nicht. ;)

Jetzt wird das Projekt, also das lokale Repository an den Server übertragen. Wenn ihr jetzt Änderungen vornimmt und wie gehabt per Commit diese in euer lokales Repository schreibt wird es nicht gleich auf dem Server synchronisiert. Dazu ist der Punkt Sync da (oder unten rechts der Pfeil nach oben). So werden auch neuere Dateien herunter geladen, falls euer lokales Repository nicht mehr aktuell ist.

Das wars…

… für heute. Im nächstem Teil wird es um Cross-Platform Entwicklung gehen. Seid gespannt. Und immer den VS2017 Tag checken! :)


Microsoft .Net Framework Logo

Heute nur ganz kurz…

Die Zeit schreitet ja voran, es gibt nicht nur neue Betriebssysteme sondern auch neue Versionen vom .Net Framework. Für den eigentlichen Benutzer unsichtbar, manchmal wegen massiven Updates sogar nervig, wird es dennoch von vielen Anwendungen benötigt.

Was ist das überhaupt?

Das Microsoft .Net Framework (für Windows und mittlerweile auch ReactOS) sowie auch das Mono Framework (Linux, MacOS) nutzen Entwickler um schneller und portabler Anwendungen zu entwickeln, da das Frarmework einem viele lästige Aufgaben abnimmt. Vergleichbar mit Java, auch wenn der Vergleich sehr hinkt, weil Java ist ja nicht grade für die Performance bekannt ist (welche eben nicht existiert)… Aber das Prinzip ist ähnlich.

Wo liegt das Problem?

Ganz einfach. Es gibt mittlerweile 3 verschiedene Versionen der Runtime, nämlich 1, 2 und 4. In wie weit 1 unterstützt wird kann ich nicht sagen, ich bin erst mit der 2 eingestiegen. Das ist der Kern der .Net Versionen 2.0, 3.0 und 3.5 (letztere haben nur die Funktionalität erweitert). Diese war schon bei Windows XP, Vista und 7 vorinstalliert. Nutzte man ein noch älteres System musste man es halt nachrüsten.

Jetzt kommt aber das Problem. Neuere Betriebssysteme wie Windows 8(.1) und Windows 10 setzen auf die Runtime 4 (also Version 4.0, 4.5 oder 4.6). Die 2er Runtime, also das Framework 3.5 in diesem Fall ist nicht mehr vorinstalliert. Will man jetzt also eine Anwendung starten die für das .Net Framework 2 kompiliert wurde erscheint eine Warnmeldung:

Anders als früher kann man das Framework nicht lokal installieren. Das geht nur von der Windows DVD (angeblich, nie selbst getestet) oder online.

Aber das Ganze ist meistens nicht nötig. Man kann .Net Framework 2 Anwendungen auch in der 4er Runtime laufen lassen.

Und wie?

Dazu muss eine Datei erstellt werden die so heißt wie das Programm was man starten möchte, mit „.config“ als Dateiendung, also zum Beispiel „MeineAnwendung.exe.config“.

Diese Datei einfach im Notepad oder einem anderen Text Editor eurer Wahl öffnen und folgenden Text hinein kopieren:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<startup useLegacyV2RuntimeActivationPolicy="true">
		<supportedRuntime version="v2.0.50727"/>
		<supportedRuntime version="v4.0"/>
	</startup>
</configuration>

Damit wird der 4er Runtime erlaubt, auch diese Anwendung auszuführen, selbst wenn sie für die 2er kompiliert wurde.

Softwareentwicklern sei trotzdem dringend angeraten die Software in der neuen Runtime ausgiebig zu testen, da es natürlich immer zu Kompatibilitätsproblemen kommen kann. Ist mir zwar bisher noch nicht passiert, aber sicher ist sicher.

Fazit:

Mal wieder so eine Kleinigkeit die man als Entwickler wissen sollte. Man stelle sich vor man erstellt eine CD / DVD mit einer Autostart Anwendung und alles was man bekommt ist das oben gezeigte Bild. Unschön. Und da es nur eine harmlose Textdatei ist, sollte es ja kein Problem sein diese gleich mit einzubinden.

Zur Not könnte man sich auf 2er Basis einen Loader schreiben der denn auf die 2er oder 4er Binary verweist, falls dies notwendig sein sollte. Ich wüsste nicht warum, aber Anwendungsgebiete sind ungefähr so vielseitig wie eine DNA. ;)