Angepinnt Visual Studio – Empfohlene Einstellungen

    • VB.NET

    Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

      Visual Studio – Empfohlene Einstellungen

      Dieser kleine Artikel richtet sich an Anfänger, aber auch an Fortgeschrittene. Es wird im ersten Teil auf die Unzulänglichkeiten der Sprache VB.NET eingegangen und ein Vergleich zu C# vorgenommen. Im zweiten Teil dieses Artikels werden Möglichkeiten gezeigt, um die Unzulänglichkeiten von VB abzustellen.

      Leider führt die Sprache VB.NET ein Dasein im Schatten von C#. Ohne Zweifel, C# ist die .NET-Sprache. Sie ist syntaktisch angelehnt an C++ und ist standardmäßig moderner als VB.NET. VB schleppt leider jede Menge Altlasten/Vereinfachungen mit sich, die vor allem für Einsteiger meist sehr verführerisch sind. Dies sind beispielsweise die voreingestellte Compiler-Option: OPTION STRICT OFF, der Microsoft.VisualBasic-Namespace und der My-Namespace.


      OPTION STRICT OFF:

      C# kennt diese Option nicht. In C# ist es zwingend erforderlich, typsicher zu programmieren.

      VB.NET-Quellcode

      1. Option Strict Off
      3. Public Class Form1
      4. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      5. Dim i As Integer = "123"
      6. MessageBox.Show(i)
      7. End Sub
      8. End Class


      In der Standard-Einstellung erlaubt es VB.NET tatsächlich, daß ein String (definiert durch "") als Zahl gesehen wird. In C# würde dies zu einem Compiler-Fehler führen und das Programm würde nicht starten.



      C# hat hier vollkommen recht. Wie soll eine Zeichenfolge auch jemals eine gültige Zahl sein? Eine Zeichenfolge kann ebenso Buchstaben beinhalten. Spätestens hier würde das VB.NET-Programm mit einem Laufzeitfehler abstürzen.

      VB.NET-Quellcode

      1. Option Strict Off
      3. Public Class Form1
      4. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      5. Dim i As Integer = "123e"
      6. MessageBox.Show(i)
      7. End Sub
      8. End Class




      Dieser Laufzeit-Fehler wäre in C# niemals in dieser Art aufgetreten, da der Compiler keine selbständigen Konvertierungen vornimmt und dies mit Fehlern anmahnt.

      Um dieses Fehlverhalten des VB-Kompilers zu beheben, bedarf es nur der Aktivierung der Compiler-Option OPTION STRICT auf ON.



      Hier verhindert OPTION STRICT ON, analog zu C#, eine automatische Konvertierung und zeigt die entsprechenden Fehlermeldungen. Das Programm lässt sich nicht kompilieren und der oben gezeigte Laufzeitfehler würde auch in VB.NET nicht mehr auftreten, da diese Fehler behoben werden müssen.

      VB.NET-Quellcode

      1. Option Strict On
      3. Public Class Form1
      4. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      5. Dim i As Integer = 123
      6. MessageBox.Show(i.ToString())
      7. End Sub
      8. End Class


      OPTION STRICT OFF macht es leider möglich, jeden erdenklichen Fehler machen zu dürfen, ohne ihn überhaupt zu sehen. Ans Tageslicht treten diese Fehler dann zur Laufzeit und hat meist einen Programmabsturz zur Folge.

      OPTION STRICT ON ist eine zwingende Maßnahme, um auf Augenhöhe mit C# zu kommen und um überhaupt ein Verständnis für Datentypen zu bekommen.


      Microsoft.VisualBasic-Namespace:

      Wie es der Name schon andeutet, kennt C# diesen Namespace nicht. Er ist standardmäßig in VB.NET importiert und beinhaltet durch die Bank nur alte Methoden und Funktionen, die in der .NET-Welt nichts mehr verloren haben. Diese Methoden und Funktionen sind nicht selten langsamer und im Grunde umständlicher als die .NET-Gegenstücke. Was hier am schwersten wiegt ist der Umstand, dass diese Altlasten das Prinzip der OOP missachten. Mitgeliefert wird diese Sammlung nur noch aus Kompatibilitätsgründen (meine Annahme).

      VB.NET-Quellcode

      1. Public Class Form1
      2. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      3. Dim s As String = Microsoft.VisualBasic.Left("1234", 2)
      4. Dim i As Integer = Microsoft.VisualBasic.Len(s)
      5. MsgBox("Alt")
      6. End Sub
      7. End Class


      C# kennt diese Befehle nicht und das ist auch gut so.



      Um zu C# aufzuschließen gilt es, den Microsoft.VisualBasic-Namespace aus seinen Projekten zu entfernen und die OOP konformen .NET-Gegenstücke zu nutzen.

      VB.NET-Quellcode

      1. Public Class Form1
      2. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      3. Dim s As String = "1234".Substring(0, 2)
      4. Dim i As Integer = s.Length
      5. MessageBox.Show("Neu")
      6. End Sub
      7. End Class



      My-Namespace:

      Wie zu erwarten war, gibt es auch diesen Namespace in C# nicht. Leider gibt es auch keinen mir bekannten Weg, diesen Namespace aus seinen Projekten zu verbannen. Der My-Namespace vereinfacht im Grunde einige Funktionen des Frameworks. Intern werden m. W. n. die .NET Klassen/Methoden/Funktionen genutzt (dies aber ohne Gewähr). Diese gekapselten Methoden und Funktionen bieten leider nicht den vollen Funktionsumfang der vollwertigen .NET-Gegenstücke. Somit sollte man diesen Namespace einfach meiden. Leider ermöglicht es gerade dieser Namespace, daß Forms ohne konkrete Instanzen aufgerufen werden können. Siehe hier diesen Artikel: Instanziierung von Forms und Aufruf von Dialogen

      VB.NET-Quellcode

      1. Public Class Form1
      2. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      3. Dim s As String = My.Computer.FileSystem.ReadAllText("test.txt")
      4. Dim result As Boolean = My.Computer.Network.Ping("www.google.de")
      5. Dim r As Rectangle = My.Computer.Screen.WorkingArea
      6. End Sub
      7. End Class


      In C# sind diese Aufrufe unbekannt



      In VB.Net bessesr gelöst durch die direkte Nutzung der Klassen/Funktionen/Methoden.

      VB.NET-Quellcode

      1. Imports System.IO
      2. Imports System.Net.NetworkInformation
      4. Public Class Form1
      5. Private Async Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      6. Dim s As String = File.ReadAllText("test.txt")
      7. Dim result As PingReply = Await New Ping().SendPingAsync("www.google.de")
      8. MessageBox.Show(result.Status.ToString())
      9. MessageBox.Show(result.RoundtripTime.ToString())
      10. Dim r As Rectangle = Screen.PrimaryScreen.WorkingArea
      11. End Sub
      12. End Class


      Sieht man sich diesen Code oben genauer an, so wird man feststellen, dass hier viel mehr Möglichkeiten gegeben sind, als durch den My-Namespace-Aufruf. Beispielsweise gibt die Klasse Ping mehr Informationen zurück, als True/False. Hier sind alle möglichen Werte gekapselt, die sich mit Sicherheit auszahlen.


      VB.NET moderner und näher an C#

      Dies waren die 3 markantesten Unterschiede (abgesehen von der Syntax) zwischen VB und C#. Wie behebt man nun diese augenscheinlichen Unzulänglichkeiten von VB? Genannt wurde: OPTION STRICT ON und der Verzicht auf den VisualBasic-Namespace, sowie My-Namespace. Für die beiden erstgenannten biete ich euch hier eine Lösung. Für den My-Namespace gibt es, wie erwähnt, keine andere Möglichkeit, als ihn einfach links liegen zu lassen.

      Dieses Video zeigt, wie OPTION STRICT global aktiviert wird. Sprich, nach dieser kleinen Einstellung wird in allen neu erstellten Projekten die zwingende Typsicherheit aktiv sein. Für bereits erstellte Projekte müsst ihr diese Option unter "My Project" im Projektmappen-Explorer nachträglich einschalten. My Project => Kompilieren.



      Das zweite Video zeigt, wie ihr den VisualBasic-Namespace aus zukünftigen Projekten verbannt und euch daraufhin eine Projekt-Vorlage erstellt. Nutzt in Zukunft nur noch diese erstellte Vorlage und ihr kommt mit diesem Namespace nicht mehr in Kontakt. Ihr könnt eure Vorlage nach Belieben konfigurieren. Beispielsweise könnt ihr zusätzliche Verweise setzen oder Namespaces standardmäßig importieren.



      Beherzigt ihr diese Vorschläge, so helft ihr erstens euch selbst, besser zu programmieren und ihr helft auch der Sprache VB etwas besser angesehen zu werden. Denn VB steht C# im Grunde in nichts nach. Letztendlich bleibt bei der Wahl der Sprache die Frage, welcher Syntax einem besser liegt.
      Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
      Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

      Von den "Deppen-Einstellungen" weg kommen

      Nochmal: Warum das alles?
      1. Zu Strict On:
        Das Kernkonzept objektorientierter Programmierung heisst: "DatenTyp".
        Kennst du den Datentyp eines Objekts, so weißt du, was es kann und was nicht, etwa Strings kann man verketten oder zerteilen (mit .Split()), Integer, Double, etc. kann man addieren oder multiplizieren, Buttons kann man klicksen, mit DateTimePickern kann man Datumse (Date) eingeben, bzw diese Eingaben auswerten.
        Von Date kann man Jahr, Monat, Tag abrufen, sowie Stunde, Minute, Sekunde, Millisekunde, uvm, usw....

        Und natürlich kann man Strings nicht multiplizieren, und von Double kann man nicht den Monat abrufen, und mit einer Textbox kann man kein Datum eingeben!

        Strict Off nun ignoriert die letztgenannten Unmöglichkeiten. Also wenn ein Objekt falsch genutzt oder zugewiesen wird (etwa ein String wird mit 3 multipliziert), dann wendet Strict Off im Hintergrund allerlei Typ-Konvertierungen an, um den Unfug dennoch möglich zu machen.

        VB.NET-Quellcode

        1. Option Strict Off
        2. Dim s = "33"
        3. Dim ss = s * 3
        Sowas geht! ;(
        Es geht natürlich nicht mehr, wenn irgendwann mal - das Prog läuft schon seit Wochen - ein User "Waldi" in den String eingibt (etwa per Textbox).
        Dann tritt der Laufzeitfehler auf, und unser Strict-Off-Progger guckt dumm 8| , warum sein Code - der doch so toll funktionierte! - nun auf einmal nicht mehr :P
        Und er ist völlig planlos, denn dass er da völlig inkompatible Dinge (ein Text ist keine Zahl!) zusammen-gewurstet hat, ist ihm überhaupt nicht bewusst, und die Fehlermeldung sagt ihm auch nichts:
        "Ungültige Konvertierung von der Zeichenfolge Waldi in Typ Double" - "ich hab doch garnix konvertiert! (Und was bitte ist eine "Zeichenfolge"?)" ;(

        Also bitte(!): Strict On - dann kommt obige Gurke garnet erst zur Ausführung.

        Sondern der Compiler meckert schon beim Hinschreiben von zeile#3:
        "Option Strict On disallows implicit conversions from 'String' to 'Double'"
        Zu deutsch: "Man kann einem String nicht automatisch in ein Double konvertieren, jedenfalls nicht bei Strict On."
        Kurz: "Ein String ist kein Double."
        Klar soweit?


      2. Zum Microsoft.VisualBasic - Namespace:
        Wie gesagt: Ein Objekt hat alles, was es braucht, entsprechend seines Datentyps. ZB ein String hat eine .Split()-Methode, mit der er sich zerteilen kann - aufzurufen so:

        VB.NET-Quellcode

        1. Dim bananaSplits As String() = "banana".Split("n"c)
        Beachte die objektorientierte Syntax: Hinter dem Objekt kommt der ., und dann zeigt Intellisense alle Methoden an, die ein String "kann" - man braucht nur "Split" auszuwählen.

        Nun kann man aber in einer OOP Sprache natürlich nachwievor auch anti-OOP programmieren:

        VB.NET-Quellcode

        1. Dim bananaSplits As String() = Split("banana", "n")
        Sieht wie dasselbe aus, ist aber eine ganz andere Split-Methode. Dieses Split() ist nun nicht die Objekt-Methode des String-Objekts, sondern ist eine globale Methode, wie sie zu hunderten im Microsoft.VisualBasic-Namespace herumfahren.
        Wenn man erst so anfängt, dann wird man nie dahinterkommen, dass die .Split()-Objekt-Methode vielfach mächtiger ist: Die kann nämlich auch mehrere Trennzeichen angeben, kann Groß-/Klein-Schreibung ignorieren, kann leere Abschnitte entfernen etc..
        All das bleibt unserm Hobby-Progger verborgen, denn er kennt nur das Split() des Deppen-Namespaces, weils ihm Intellisense ständig unter die Finger spielt.
        Auch die fabelhafte String.Substring()-Objekt-Methode wird er nie kennenlernen, denn der Deppen-Namespace speist ihn mit Anti-OOP-Gurken ab wie Left$(), Right$() und Mid$().

        Weiters wird er kaum jemals überhaupt die Systematik des Frameworks kapieren, und dass es das Datentyp-Konzept beinhaltet, dass man jederzeit nachgucken kann, was ein Datentyp kann: VisualStudio richtig nutzen
        Und Datentypen können - im Wortsinn! - unvorstellbar viel: etwa die String-Klasse verfügt über über 200 Methoden und Properties (im Ernst: einfach mal VisualStudio richtig nutzen und nachgucken ;) )!

        Also bitte(!): Den General-Import des Deppen-Namespace rausschmeissen.
        Das entfernt die Anti-OOP - Methoden nicht aus dem System, aber Intellisense hört auf, einem das Zeugs ständig unter die Finger zu spielen.
        Dieser kleine Unterschied eröffnet die Möglichkeit, äh die Wahrscheinlichkeit - nein: die Höchstwahrscheinlichkeit, dass man nun die Objekt-Methoden der Objekte nutzt - anders gesagt: dass man objektorientiert zu programmieren anfängt.

      Wie beides einzustellen ist - 1) Strict On und 2) General-Import deaktivieren - ist ja in Post#1 in den Videos gezeigt.
      Und zwar global fürs Projekt, und sogar fürs ganze VisualStudio
      Also wenn man nur will, kann man sich des Unfugs in 5 min ein für allemal entledigen.

      Warum Programmierer sich an Unfug klammern
      Meist entwickeln Programmierer enorme Widerstände, wenn man sie auffordert, Option Strict On zu setzen, und den General-Import auf Microsoft.VisualBasic zu entfernen. Also was sich eigentlich in 5 Minuten erledigen liesse, entwickelt sich zu unerfreulichen Diskussionen, die sich über zig Posts und Tage hin erstrecken können.

      Über die Gründe des Widerstandes kann man nur mutmassen:
      • sie können den sachlichen Begründungen der Notwendigkeit nicht folgen (natürlich nicht: Weder Datentypen noch die Objekt-Orientierung der Sprache konnten sie bisher wahrnehmen)
      • es scheint ihnen mühsam, die vielen nun sichtbar gewordenen Fehler zu korrigieren
      • zunächst sind sie damit überfordert (natürlich: Datentypen und Objekt-Orientierung lernen sie jetzt ja erst kennen)
      • sie wollen keine liebgewonnenen Gewohnheiten aufgeben für etwas neues, was sie erst noch lernen müssen (und sicher noch viel lieber gewinnen werden)
      • Sie sehen keinen Nutzen, zumal das Programm doch bereits lief
      • sie fühlen sich bevormundet
      • der Nachdruck, mit dem man dennoch darauf bestehen muss, verärgert sie (Trotzreaktion)
      • sie wollen die Tatsache nicht wahrhaben, dass sie eigentlich noch gar nicht programmieren können
      Aber es nützt nichts: Mit aktivierten Deppen-Einstellungen ist Vb.Net keine ernstzunehmende Programmiersprache, und nicht wert, sich damit zu beschäftigen.
      Sondern ist ein besseres Scripting-Tool für Guttenberg-Akrobaten, die nichts von dem verstehen (wollen), was sie in ihren Editor einkopieren.
      So unerfreulich es ist: hier gibt es keine andere HIlfe, als unerbittlich darauf zu bestehen, die Einstellungen so zu korrigieren, dass VB.Net eine ordentliche Sprache wird - c# ebenbürtig.

      Leute, die das nicht akzeptieren, sollten besser mit c# anfangen, da muss man den Quatsch nicht endlos herum-diskutieren - es gibt ihn einfach nicht :thumbup:

      Noch einmal: Bitte guckt die Videos in Post#1 an - sind ziemlich am Schluss

      Wie dem auch sei:
      Hat man sich überwunden, die Deppen-Einstellungen zu deaktivieren sieht man sich plötzlich vielen Fehlern gegenüber (evtl. hunderten), die vorher nicht dagewesen zu sein schienen. Hier braucht man eine Strategie, nach der man die Korrekturen häppchenweise durchführen kann, denn bei zig Fehlern alle auf einen Rutsch zu korrigieren, ohne neue einzubauen ist eiglich ausgeschlossen - es ist ja Neuland!
      Und andererseits solange nicht alle Fehlermeldungen verschwunden sind, kann man keinen Testlauf starten.

      1) Die Deppen-Usages sichtbar machen
      Daher empfehle ich, für jede Datei händisch die Deppen-Einstellungen wieder zu aktivieren, indem man am Anfang jeder Datei hinschreibt:

      VB.NET-Quellcode

      1. Option Strict Off
      2. Imports Microsoft.VisualBasic
      Damit hat man den zuvor gottlob entfernten projektweiten Blödsinn dateiweise nun wieder reingemacht, mit eiglich nur dem kleinen Unterschied, dass er nun sichtbarer ist.
      Und man kann nun Datei für Datei vorgehen, sich dabei etwa zuerst Strict On vorknöpfen, danach den Deppen-Namespace.
      Und auch hier: Zunächst den Blödsinn einfach nur noch sichtbarer machen.

      1a) Geht im Falle Strict Off so:
      1. Die Option Strict Off - DeppenZeile aus der einzelnen Datei wieder entfernen, sodass der Compiler die Fehler dieser Datei wieder anzeigt
      2. bei jedem Fehler die zuvor unsichtbare Typ-Konvertierung nun explizit hinschreiben - es geht in jedem Falle mit der CType-Anweisung, also z.B.

        VB.NET-Quellcode

        1. Dim i as Integer = CType(Textbox1.Text, Integer)
        Man kann auch selbst versuchen, wirkliche Korrekturen vorzunehmen, hier etwa mit Integer.Parse()
        Aber grade Strict-Off-Müll löst man zu 80% nicht dadurch auf, dass man Datentypen konvertiert, sondern von vornherein die passenden Typen verwendet. Und wenn man Datentypen bisher noch nie wahrgenommen hat steht man natürlich wie Ochs vorm Berg.
        Also sich Helfen lassen ist einfacher, lehrreicher und gewährleistet sicherer, dass man nicht gleich den nächsten Bug einbaut. Daher ruhig das eigentlich dumme CType verwenden - das funktioniert sicher, und vertuscht oder verschlimmert erstmal nichts.


      1b) Für den Microsoft.VisualBasic-Import gehts vom Prinzip (sichtbar machen) her genauso:
      1. Die Imports Microsoft.VisualBasic - DeppenZeile aus der Datei wieder entfernen, sodass der Compiler die Fehler wieder anzeigt
      2. bei jedem Fehler die bemeckerte Methode nun eben vollqualifiziert aufrufen, also

        VB.NET-Quellcode

        1. 'statt
        2. Dim s As String = Left("banana",2)
        3. 'vollqualifiziert
        4. Dim s As String = Microsoft.VisualBasic.Left("banana",2)
        Auch das geht in jedem Fall, denn auch das ist eiglich keine Korrektur, sondern nur das ausdrückliche Hinschreiben desselben Blödsinns, der schon vorher da stand.
        Hier kann man schon eher eigene Versuche unternehmen, denn mit Böses aus VB6/VB2003 - und die richtigen VB.NET-Alternativen liegt eine recht umfassende Auflistung der Framework-Alternativen vor.
        Doch auch hier ists kein Beinbruch, Hilfe in Anspruch zu nehmen, denn nicht selten sind Umstrukturierungen möglich und naheliegend, die zig Zeilen unübersichtlichen Codes in einen einfachen 3-Zeiler konzentrieren können.

        Spezieller Hinweis: nicht darstellbare Zeichen innerhalb von Strings, wie Zeilvorschub, Tab, " fügte man früher mit vbCrLf, vbTab, ChrW(34) ein. Hier gibts die elegante Möglichkeit, einen ganz punktuellen GeneralImport auf Microsoft.VisualBasic.ControlChars zu setzen - siehe: Link.
        Und " kann man direkt im String notieren, durch Verdopplung, also so:

        VB.NET-Quellcode

        1. Messagebox.Show("ein ""String"" im String")
        2. Messagebox.Show("""")


      2) Sich Helfen lassen
      Als nächstes sollte man einen Teil (den hässlichsten) des so verunstalteten Codes einfach auf VBP posten, mit Bitte um Hilfe.
      Weil wo man als "Bisher-Depp" überhaupt keinen Ansatz für hat, das korrigiert jmd, der Datentypen "kann" in weniger als einer Minute.
      Dazu zwei oder drei Erklärungen, und dann findet man schnell hinein und kann die anderen hundert Fehler selbst berichtigen.
      Auch erhält man dabei wertvolle prinzipielle Vorschläge, etwa für Zahlen-Eingaben NumericUpdowns zu nehmen statt Textboxen - an solchen Punkten fängt die Anwendung an, sich wirklich zu wandeln, und in gleichzeitig mehrfacher Hinsicht sich zu verbessern (Benutzerführung, Wartbarkeit, Stabilität,...)

      Dieser Beitrag wurde bereits 13 mal editiert, zuletzt von „ErfinderDesRades“ ()

      In diesem Post möchte ich "schnell zur Sache kommen". Warum diese Einstellungen wichtig sind, wurde ja bereits oben erklärt, aber ich befürchte, dass sich Einsteiger schwer tun, die Einstellungen auch richtig anzupassen, wenn sie nicht so ganz verstehen, was das alles eigentlich bedeutet.

      Falls Du also hierher verwiesen wurdest, aber das, was in den vorhergehenden Posts gesagt wurde nicht wirklich Sinn ergibt, dann steht hier für Dich zusammengefasst, was Du machen solltest.

      Inhalt:
      • Option Strict On
        • Bei neuen Projekten: Hier wird erklärt, wie Option Strict für alle Projekte, die Du in Zukunft erstellst, automatisch auf On gestellt ist.
        • Bei bestehenden Projekten: Wenn Du bereits Projekte erstellt hast, wird Option Strict mit dem obrigen Punkt nicht retroaktiv auf On gestellt. Hier siehst Du, wie Du das manuell nachholen kannst.
      • Microsoft.VisualBasic-Namespace
        • Bei neuen Projekten: Hier wird erklärt, wie Du eigene Projekt-Templates erstellen kannst, damit der Generalimport des Microsoft.VisualBasic-Namespaces bei neuen Projekten automatisch nicht mehr da ist.
        • Bei bestehenden Projekten: Hier wird erklärt, wie Du den Generalimport des Microsoft.VisualBasic-Namespaces bei bestehenden Projekten entfernen kannst. Wie bei Option Strict On wird das mit dem obrigen Punkt nicht automatisch für bestehende Projekte gemacht.
      • My-Namespace
      • Sonstige Tricks


      Option Strict On bei neuen Projekten:
      Das geht ganz einfach:

      In der Menüleiste auf "Extras" klicken und dann "Optionen..." auswählen:

      Falls hier der Haken bei "Alle Einstellungen anzeigen" nicht gesetzt ist, sollte das jetzt gemacht werden.
      Dann "Projekte und Projektmappen" und "VB-Standard" auswählen.
      Auf der rechten Seite kann nun Option Strict von Off auf On geändert werden.
      OK klicken und das war's.


      Option Strict On bei bestehenden Projekten:
      Wenn man die Standardeinstellung auf On geändert hat, wird das nicht automatisch für bestehende Projektmappen übernommen. Falls Du schon Projekte erstellt hast, solltest Du das hier für jedes dieser Projekte machen:
      Öffne das Projekt in Visual Studio.

      Öffne die Projekteigenschaften, indem Du in der Menüleiste auf "Projekt" und "XYZ-Eigenschaften..." klickst, wobei "XYZ" für den Projektnamen steht.

      Öffne den Tab "Kompilieren".
      In dem Tab kann Option Strict für dieses Projekt auf On geändert werden.
      Speichern nicht vergessen (Strg+S oder links oben mit dem Diskettensymbol).

      Falls Du mehrere Projekte in einer Projektmappe hast, solltest Du das für jedes dieser Projekte machen. Hier ist es einfacher, die Projekteigenschaften über den Projektmappenexplorer öffnen:

      Klicke im Projektmappenexplorer mit der rechten Maustaste auf das Projekt und klicke dann auf "Eigenschaften". Dadurch öffnen sich auch die Projekteigenschaften. Mach das für alle Projekte in der Projektmappe.


      Microsoft.VisualBasic-Namespace bei neuen Projekten:
      Das ist etwas komplizierter und Du musst das nicht machen, wenn es Dir zu viel Arbeit ist und wenn Du nicht vergisst, bei allen neuen Projekten den Generalimport manuell zu entfernen.
      Visual Studio verwendet sogenannte "Project Templates" für neue Projekte. In diesen Templates steht, welche Generalimporte standardmäßig ausgewählt sind.
      Die vorinstallierten Templates befinden sich hier:
      Bei der Express-Edition: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\VBExpress\ProjectTemplates
      Bei anderen Editionen: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\
      Wobei der Teil Microsoft Visual Studio 10.0 von Version zu Version unterschiedlich ist. Bei Visual Studio 2010 ist es Microsoft Visual Studio 10.0, bei Visual Studio 2015 dagegen ist es Microsoft Visual Studio 14.0. Du musst einfach durchgucken, welche Version und Edition Du installiert hast und entsprechend diesen Pfad öffnen. Ich verwende hier einfach mal die 2010-er Version.
      Bei der Express-Edition: Öffne den einzigen Unterordner 1031.
      Bei anderen Editionen: Öffne den Unterordner VisualBasic\Windows\1031. Hier findest Du auch Templates für andere Sprachen und für andere Kategorien von Projekten (z.B. Office). Das gibt es so bei der Express-Edition nicht, denn das sind separate Installationen pro Programmiersprache und da gibt es auch nur 5 vorinstallierte Templates.
      Beachte: Der Ordner mit der Zahl steht für die Sprache. 1031 ist Deutsch. 1033 wäre Englisch. Siehe science.co.il/Language/Locale-codes.asp für eine Liste. Im Normalfall ist nur eine Sprache installiert. Öffne den Ordner, den es bei Dir gibt.
      Da sollten jetzt ein Haufen Zip-Dateien drin sein.
      Es ist keine gute Idee, die vorhandenen Templates zu überschreiben. Bei einer Neuinstallation oder wenn Updates installiert werden sind die Änderungen futsch. Stattdessen gibt es im Benutzerverzeichnis einen Ordner, in dem man eigene Templates ablegen kann: C:\Users\Niko\Documents\Visual Studio 2010\Templates\ProjectTemplates\Visual Basic. Auch hier musst Du wieder darauf achten, dass Du den Ordner für die passende Version öffnest (also z.B. Visual Studio 2015 statt Visual Studio 2010). Und natürlich musst Du Deinen Benutzernamen verwenden. Und auf anderen Betriebssystemen (insbesondere XP) kann der Pfad natürlich etwas anders aussehen.
      Kopiere alle Templates, die Du verändern möchtest, in einen Ordner auf dem Desktop. Das dürften am ehesten "ClassLibrary", "ConsoleApplication", "WindowsApplication" und "WPFApplication" sein, aber nimm einfach das, was Du häufig verwendest.
      Mach dann für jedes Template folgendes:
      • Extrahiere die Dateien. Vorzugsweise in einen neuen Ordner, damit die Dateien nicht in der Gegend herumfliegen.
      • Öffne die einzige, vorhandene .vbproj-Datei in einem Editor. Beim ClassLibrary-Template wäre das die classlibrary.vbproj-Datei. Zur Not tut's Notepad, aber Du solltest einen besseren Editor, wie z.B. Notepad++ verwenden.
      • Suche <Import Include="Microsoft.VisualBasic" /> und entferne die Zeile. Wie Du sicher rauslesen kannst, ist diese Zeile für den Generalimport, den wir nicht wollen, zuständig. Ist die Zeile nicht mehr da, ist auch der Generalimport nicht mehr da.
      • Speichere die Datei.
      • Öffne die einzige, vorhandene .vstemplate-Datei. Da drin befinden sich Metadaten zum Template. Es gibt jetzt nämlich folgendes Problem. Das bearbeitete Template hat den gleichen Namen wie das existierende und deshalb kann man sie dann in Visual Studio nicht unterscheiden.
      • Suche in der Datei <Name Package="{164B10B9-B200-11D0-8C61-00A0C91E29D5}" ID="3000" />. Wobei sich der Zeichensalat und die ID von Template zu Template unterscheiden (wichtig ist <Name am Anfang). Ersetze das durch <Name>Eigene Klassenbibliothek</Name> oder irgendwas in der Richtung. Natürlich sollte der Name zum Template passen. Das ist dann der Name, der in Visual Studio in der Liste angezeigt wird.
      • Jetzt hast Du noch die Möglichkeit, die Reihenfolge zu ändern, in der die Templates angezeigt werden. Das ist nicht unbedingt nötig, aber es erleichtert, die eigenen Templates zu finden. Suche dazu <SortOrder>20</SortOrder> (die Zahl ist von Template zu Template unterschiedlich) und ersetze die Zahl durch eine andere. Je kleiner die Zahl, desto weiter oben wird das Template angezeigt. Eine Zahl von 1 bis 5 reicht, um das Template ganz oben einzureihen.
      • Nicht vergessen, die Änderungen zu speichern.
      • Kopiere die geänderten Dateien (oder einfach alle Dateien) zurück in die Zip-Datei und überschreibe bestehende Dateien.

      Sobald Du alle Templates bearbeitet hast, kopiere die Zip-Dateien in den C:\Users\Niko\Documents\Visual Studio 2010\Templates\ProjectTemplates\Visual Basic-Ordner (wie gesagt Version und Benutzername beachten).
      Wenn Visual Studio das nächste Mal geöffnet wird, sind die neuen Templates vorhanden.



      Microsoft.VisualBasic-Namespace bei bestehenden Projekten:
      Das ist auch nicht schwer.

      Öffne wie oben erklärt die Projekteigenschaften. Also in der Menüleiste auf "Projekt" und dann auf "XYZ-Eigenschaften..." klicken.

      Öffne dann den Tab "Verweise".
      Im unteren Bereich gibt es eine Liste, die alle Namespaces zeigt. Die, bei denen Die CheckBox gecheckt ist, sind überall im Projekt importiert. Das ist mit "Generalimport" gemeint (genau genommen heißen die "projektweite Importe").
      Stelle sicher, dass bei Microsoft.VisualBasic kein Häkchen gesetzt ist. Die Namespaces werden nach "importiert oder nicht importiert" und anschließend nach dem Namen sortiert. Achte darauf, nicht versehentlich irgendwas zu verändern, indem du zweimal auf den selben Eintrag klickst.
      Auch hier speichern nicht vergessen (Strg+S oder links oben mit dem Diskettensymbol).


      My-Namespace:
      Der My-Namespace kann leider nicht deaktiviert werden. Da musst Du Dich einfach bei der Nase nehmen und die Dinge, die da drin sind, nicht verwenden (ausgenommen My.Resources und My.Settings).


      Sonstige Tricks:

      Erweiterte Einstellungen:
      Zeige die erweiterten Einstellungen an:

      Klicke in der Menüleiste auf "Extras" und setze unter "Einstellungen" einen Haken bei "Erweiterte Einstellungen". Dadurch werden einige Menüelemente angezeigt, die sonst ausgeblendet sind.

      Zeilennummern anzeigen:
      Zeige die Zeilennummern an:

      Klicke in der Menüleiste auf "Extras" und dann auf "Optionen...".

      Falls hier der Haken bei "Alle Einstellungen anzeigen" nicht gesetzt ist, sollte das jetzt gemacht werden.
      Klicke unter "Text-Editor" auf "Alle Sprachen" und setze auf der rechten Seite einen Haken bei "Zeilennummern". Dadurch werden im Editor die Zeilennummern angezeigt.

      Einstellungen exportieren:
      Wann immer Du etwas in den Optionen änderst, also unter "Extras" -> "Optionen...":

      solltest Du Deine Einstellungen exportieren. Wenn Du Visual Studio mal neu installierst oder auf einem anderen Computer installierst, dann musst Du nicht alles von Hand neu einstellen.

      Klicke in der Menüleiste auf "Extras" und unter "Einstellungen" auf "Einstellungen importieren und exportieren...".

      Im Assistenten "Ausgewählte Umgebungseinstellungen exportieren" auswählen.

      Die Exporteinstellungen und der Name der Datei müssen üblicherweise nicht geändert werden. Es reicht, einfach auf "Weiter" und "Fertig stellen" zu klicken.


      Wenn Du das alles eingestellt hast, dann ist Deine IDE im Top-Zustand.
      "Luckily luh... luckily it wasn't poi-"
      -- Brady in Wonderland, 23. Februar 2015, 1:56
      Desktop Pinner | ApplicationSettings | OnUtils

      Noch eine kleine Ergänzung:
      Was in vielen Thread schon genannt wurde, aber hier noch gar nicht gelistet ist, obwohl es dazu gehört:
      In den Projekteigenschaften bei Kompilieren alle Regler auf Fehler stellen, ggf. beschleunigt durch den Haken bei Alle Warnungen als Fehler behandeln (wobei dadurch aber Keine nicht automatisch zu Fehler wird!). Option Strict On schaltet nämlich nur einige dieser Schalter mit um.



      Durch die Verwendung von FxCopAnalyzers kann man noch viel mehr rausholen, es bedarf da aber eine genaue Abwägung der Regeln, sonst wird man mit Änderungsvorschlägen bombardiert, die etwas über das Ziel hinausschießen.

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

      Mit .NET 5.0 hat auch eine neue Art von Projekttyp Einzug gefunden, welcher auf den ersten Blick etwas schwierig vom "alten" Projekttyp bei Erstellung unterscheidbar ist, v.a. da sie nicht direkt untereinander stehen (es sei denn, man benutzt die Vorlagensuche mit z.B. dem Begriff windows forms app):


      (Screenshot aus Visual Studio Community Edition 2022 Version 17.0.0 Preview 7.0, Stand 07.11.2021, hier am Beispiel WinForms-App mit VB.NET)

      Diese Projektvorlage bringt nicht nur Verwirrung für unabsichtliche Umsteiger mit sich, da diese etwas anders tickt als die alten .NET-Framework-Projekte, sondern auch noch von Haus aus automatisch ein paar Standardimporte bei den Namespaces - leider auch den o.g. Microsoft.VisualBasic-Namespace. Leider lässt dieser sich nicht ohne weiteres entfernen. Beim Versuch rebelliert VS:


      Wie die Fehlermeldung etwas kryptisch sagt, ist der Import eine Vorgabe der gewählten Projektvorlage. Um diesen und auch andere Vorlagen-Standardnamespaces trotzdem zu entfernen, muss man die Projektdatei (Endung .vbproj oder bei C#-Projekten .csproj) manuell bearbeiten. Dazu im Projektmappen-Explorer die Projektdatei (nicht die Projektmappe!) anwählen, mit der Maus einen Rechtsklick, um das Kontextmenü zu öffnen und dann auf Projektdatei bearbeiten*.

      Nun fügt man in einer leeren Zeile folgenden Code ein, am besten nach dem ersten PropertyGroup-Abschluss, also nach </PropertyGroup> (man achte auf den Slash vor PropertyGroup!):

      XML-Quellcode

      1. <PropertyGroup>
      2. <DisableImplicitNamespaceImports>true</DisableImplicitNamespaceImports>
      3. </PropertyGroup>


      Danach speichert man die Datei und die Namespaces sind raus.

      Quelle für den Trick: GitHub-Microsoft-Issues

      * noch eine kleine Änderung gegenüber .NET-Framework-Projekten: Man kann die Projektdatei direkt bearbeiten, ohne vorher das Projekt entladen zu müssen.
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

      VaporiZed schrieb:

      * noch eine kleine Änderung gegenüber .NET-Framework-Projekten: Man kann die Projektdatei direkt bearbeiten, ohne vorher das Projekt entladen zu müssen.
      Auch bei Framework-Projekten kann man die Projektdatei bearbeiten, ohne das Projekt entladen zu müssen, allerdings nicht im Visual Studio, sondern z.B. im Notepad++.
      Nach Speichern der Projektdatei sagt das Studio, dass die Projektdatei extern geändert wurde und fragt, ob sie nachgeladen werden soll:
      Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
      Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
      Ein guter .NET-Snippetkonverter (der ist verfügbar).
      Programmierfragen über PN / Konversation werden ignoriert!