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! :)


Visual Studio 2017

Visual Studio 2017…

Ok. Ich programmiere schon seit ich 7 Jahre alt bin. Zugegeben, wirklich programmieren konnte man es damals noch nicht nennen. Zur damaligen Zeit, kann man sich heute kaum mehr vorstellen, gab es noch kein Internet. Wollte man neue Software haben hatte man 3 Möglichkeiten:

  1. Selber programmieren
  2. Disketten oder Datasetten kaufen
  3. Computerzeitschriften kaufen und Listings abtippen

Für mich kam damals natürlich nur letzteres in Frage. Daher meine ersten Erfahrungen mit Basic. Dabei ist es denn auch geblieben. Von einem Schneider CPC464 rüber zum PC mit MS-DOS und QBasic, über Visual Basic 1 zu 6, dann die VB.Net Schiene. Und hier hing ich Ewig auf Visual Studio 2008 / Visual Basic 2008 Express fest. Primär lag das daran weil das neuere Visual Studio 2010 fehlerhaft war und mir den Debugger des installierten 2008'ers, welchen ich weiterhin brauchte, erfolgreich geschrottet hat. Neuinstallation war nötig.

Aber es wird Zeit mit der Zeit zu gehen. Also mal das neue Visual Studio besorgt. Es hat ja auch diverse Vorteile, auf die gehe ich aber in den anderen Teilen dieser Serie ein. Nur so viel sei vorweg gesagt: Es wird auch unter Anderem auch noch um einige neue Eigenheiten der Sprache Visual Basic gehen, um die Veröffentlichung von Anwendungen und auch Cross-Platform Entwicklung ist ein Thema.

Die Tools die ich verlinke sind zwar fast nur für Windows, weil das mein Primärsystem ist, aber einiges gibt es auch für MacOS oder Linux. Vielleicht nicht ganz so komfortabel, einiges muss angepasst werden, aber so ist es halt.

Wie auch immer, diese Serie soll meine Erfahrungen und Lernerfolge wiedergeben, vielleicht hilft es ja auch dem Einen oder Anderen, etwas professioneller zu arbeiten.

Die Community Edition vom Visual Studio ist gratis, wie die Express Editionen früher. Und schon geht es los…

Systemvoraussetzungen

  • Windows 7 oder neuer.
  • 1,8GHz CPU oder besser.
  • Teilweise wird 64 Bit CPU und Betriebssystem vorausgesetzt.

Das sind aber schon extreme Mindestvoraussetzungen. Inoffizielle Mindestvoraussetzungen, also Anmerkungen meinerseits:

  • Kaffee! Weil, das wird dauern.
  • Schnelle Internetverbindung vorausgesetzt (je nach Konfiguration werden ~10-20GB geladen, ggf. sogar mehr).
  • Ohne SSD im Rechner (200GB aufwärts), ersetze Punkt 1 mit "Massig viel Kaffee! Es wird ewig dauern.".
  • 4GB RAM sind absolutes Minimum.

Naja, mein System passt noch, also ab dafür.

Installation

Heutzutage läd man sich ja keine Anwendungen runter, man läd sich Downloader runter die dann die Anwendung runter laden. Diese "schöne" neue Welt übertrifft das Visual Studio noch. Man läd sich einen Downloader runter der das Setup runter läd welches wiederum das Visual Studio runter läd. Aaahja. Naja, hat auch Vorteile, man läd nur Komponenten runter die man ausgewählt hat und die zumindest halbwegs aktuell sind. Den ersten Schritt hätte man sich trotzdem schenken können.

Ist das Setup gestartet dann kann man auswählen was man installieren möchte. Hier kann natürlich jeder das auswählen was er möchte, für mich - und die Folgeteile dieser Serie - sind aber die Punkte

  • .NET-Desktopentwicklung
  • ASP.NET und Webentwicklung
  • Plattformübergreifende .NET Core-Entwicklung

benötigt. Android und iOS lasse ich mangels vorhandenen Geräten links liegen, C++ ist so eine Sache für sich, ich stehe einfach nicht so auf diese Ansammlung von Smiley Gangbang's. Auch wenn ich in dieser Serie wohl nicht großartig auf ASP.NET eingehen werde, empfehle ich es trotzdem, wenn auch nur zum Bearbeiten von .css und anderen Webdateien, weil man in seiner Homepage was anpassen möchte.

Visual Studio Download

Weitere Sachen

Hier greife ich jetzt etwas vor, aber wenn ihr eh schon grad am runter laden seid, zieht das gleich mit. Es handelt sich um extrem hilfreiche Tools auf die ich später auch noch eingehen werde. Hier beschreibe ich nur kurz das Warum, aber nicht das Wie. Bitte erst zu Ende lesen, manchmal ist die Reihenfolge wichtig.

  • Git - Eine Versionskontrolle. Da das Thema sehr komplex ist mehr dazu später. Must-Have! Solltet ihr einen Windows Server haben und wollt euren Quelltext lieber damit synchronisieren statt irgendeinem Onlinedienst wie GitHub, wäre Bonobo Git Server einen Blick wert, den nutze ich selber. Für den lokalen Rechner braucht ihr das aber nicht.
  • Visual Studio Spell Checker - Der Name sagt alles, Rechtschreibprüfung für den Quelltext (wie Variablennamen) und Kommentare. Visual Studio muss erst fertig installiert sein!
  • HTML help workshop - Benötigt von Sandcastle Help File Builder, man selbst nutzt es nicht direkt.
  • Sandcastle Help File Builder - Benötigt um Hilfedateien (.chm, .docx) zu erstellen. Visual Studio muss erst fertig installiert sein! HTML Workshop sollte installiert sein!
  • OfficeToPDF - Konsolenanwendung um Office Dokumente in .pdf umzuwandeln. Setzt ein installiertes Office 2007 (besser 2010) oder neuer voraus.
  • Resource hacker - Sehr nützlich um in Resourcen von Anwendungen (wie Bilder, Icons, …) rein zu schauen und diese sogar zu bearbeiten.
  • ILSpy - Hiermit kann man in den Quelltext von .Net Binärdateien rein schauen. Man bekommt zwar natürlich nicht 1zu1 den Quelltext, aber häufig genug reicht das aus was man sieht. Alternativ wäre noch der .Net Reflector zu nennen, allerdings verachte ich die Firma Red-Gate! Als die Anwendung früher von Lutz Roeder hergestellt wurde war sie noch gratis und lief perfekt, jetzt muss man dafür n Kleinkredit aufnehmen. Get lost! Vielleicht findet ihr ja noch eine alte Version, packt diese mit in eure Sammlung und nicht Updaten!
  • ConfuserEx - Anwendung um Obriges, also das Dekompilieren zu verhindern. Ich erwähne es der Vollständigkeit halber, rate aber von der Nutzung eher ab. Genauer gehe ich darauf in einem späteren Teil ein. Fazit kurz vorweg: Bringt nicht viel Nutzen, aber jede Menge Nachteile, irrelevant welchen Obfuscator man nutzt (es gibt Alternativen, sowohl freie als auch kommerzielle).
  • Visual Studio Image Library - Verschiedene Bilder und Icons die gratis zur Verfügung gestellt werden (Lizenz beachten!). Vorsicht, ist 'ne Menge. Zieht euch die für alle Versionen, es sind Bilder, Bildern ist es egal ob ihr nun Visual Studio 2017 oder 2012 nutzt. Die vom Visual Studio 2005, 2008 und 2010 stehen leider nicht offiziell zum Download zur Verfügung, aus lizenztechnischen Gründen biete ich diese auch nicht an, sorry. Man könnte aber auf die Idee kommen danach zu suchen. VS2005ImageLibrary.zip, VS2008ImageLibrary.zip, VS2010ImageLibrary.zip. Könnte man. Aber ich hab' nix gesagt. Vieles wird in den Versionen eh gedoppelt sein.
  • 7zip, aber auch 7za.exe - Sehr gutes Komprimierungsprogramm. Speziell wird aber die 7za.exe benötigt, welche neuerdings im Extra Archiv ziemlich versteckt ist.
  • mkisofs.exe - Leider finde ich keine Projekthomepage mehr hierzu, daher hoste ich die Datei auf meinem Server. Ggf. passe ich den Link an. Es handelt sich um ein Konsolenanwendung um Images zu erstellen, z. B. CD Images, aber auch andere Typen können erstellt werden. Nette Besonderheit: Es unterstützt das Suchen nach Duplikaten und entfernt diese transparent, genau aus diesem Grund für mich unverzichtbar. Mehr dazu in einem späteren Teil.
  • Photoline (aktuell 59€) oder ein ähnliches vernünftiges Bildbearbeitungsprogramm. Häufig nicht kostenlos. (Klar, es gibt Gimp oder Paint.Net, mit denen konnte ich mich aber nie anfreunden. Persönliche Vorliebe und so. Die andere Alternative, welche bei mir den Titel "Der strudelfressende Nimmersatt des Geldbeutels" zu Recht bekommen hat, ernenne ich hier noch nicht mal namentlich. Ihr wisst welchen ich meine.)

Die meisten Programme werden entweder zu Dokumentationszwecken oder später zur Veröffentlichung verwendet. Wie genau sage ich denn wenn wir so weit sind. 

Solltet ihr Windows ≥8 verwenden dann rate ich an das .Net Framework 3.5 zusätzlich zu dem installierten 4.x zu installieren, sonst können eure Anwendungen nur für die neuen Versionen erstellt werden, was ältere Betriebssysteme ausschließt. Eine Anleitung hierfür bietet Microsoft selbst: https://docs.microsoft.com/de-de/dotnet/framework/install/dotnet-35-windows-10 (Danke, @LotadaC!)

Einrichtung

Ist alles heruntergeladen und (ggf.) installiert kann man das neue Visual Studio mal starten und einrichten. Ich persönlich bevorzuge das dunkle Theme, auch wenn es hier und da noch etwas Feintuning bedarf. Spielt hier erst mal etwas mit rum, was euch gefällt, was nicht. Im nächsten Teil geht's weiter. Was ich zu Erst ändere ist das Einrücken mit Leerzeichen. Es ist einfach nur falsch. War es immer und ist es immer noch. Dazu sind Tabs da! Wer so was will zentriert auch Text in Word mit Leerzeichen und Augenmaß. Es ist einfach nur dumm.

War's das?

Natürlich nicht, nur für heute. Sucht nach dem Tag VS2017, da findet ihr alle Beiträge zu der Serie. Allerdings (während ich diesen Post schreibe) ist die Serie noch im Entstehen, ist ja der erste Teil. Schaut also öfters mal vorbei. Smile

 

p.s.: Für die Ernennung ggf. kommerzieller Software ist deren Qualität und mein Vertrauen darin verantwortlich, keinerlei finanziellen Interessen. Selbst hätte ich Geld hierfür bekommen können, hätte ich das Angebot dankend abgelehnt, wie schon mal geschehen! Dieser Blog ist frei von kommerziellem Sponsoring.