Hallo zusammen.

Vielleicht wird's ja ein Sammelthread.
Ich würd gern Fehler in Visual Studio hier von Euch gegenprüfen lassen. Und wenn Ihr die bestätigen könnt, wär's natürlich sinnvoll, wenn Ihr das dann bei Microsoft »upvoted«, damit es auch von denen wahrgenommen wird. Ich meld zwar immer mal wieder was, aber das geht denen am Oberarm vorbei, wenn nur ich es melde.

Das Ganze soll aber kein Einzelding werden, sondern jeder darf gerne Fehler, die in Visual Studio aufgrund von Visual Studio (!) auftreten, hier posten und gegenchecken lassen. Wichtig ist natürlich, dass es reproduzierbar ist und dass ihr das dann bei Microsoft selber meldet. Dafür gibt's ja die VS-Funktion ein Problem melden. Auch Verbesserungsvorschläge sind sinnvoll, wenn es um fehlerhaftes oder sinnloses VS-Verhalten geht.
Bitte auch immer die von Euch verwendete Visual Studio-Version hier vermerken, damit wir es auch richtig gegenprüfen können.
--- Update am 19.02.2024: Gebt bitte auch an, wenn Ihr nicht das deutsche Sprachpaket, also eine deutsche Oberfläche verwendet. Wie in Post#34 zu sehen, kann auch das relevant sein! ---


Ich mach mal den Anfang: ich nutze Version 17.5.0 Preview 2.0, habe folgenden Code

wähle das Foo nach dem If und drücke Strg+R, Strg+M um den Ausdruck in eine Methode zu extrahieren (es ist Testcode zur Reproduktion des Fehlers, kein sinnvoller Code!). Es kommt die Meldung, dass nicht alle Pfade einen Rückgabewert haben.

Das Problem: Egal, ob ich [ja] oder [nein] anklicke, es passiert nix.
Wer das bestätigen kann, darf gerne voten: MS-Feedback-Link


##########

Dann ist mir noch was aufgefallen:
Wenn man einem Control einen ungültigen Namen im Designer verpasst, kommt ne Meldung:

Aber egal, ob mal auf OK oder Abbrechen klickt, wird der Name zurückgesetzt. Also kein Funktionsunterschied. Es sollte ein Button entfernt werden oder bei einem Button sollte man die Möglichkeit haben, den fehlerhaften Namen zu korrigieren.
Der MS-Feedback-Link, falls das bei Euch auch so ist und Ihr den Vorschlag sinnvoll findet.

Habe die Datei im angegebenen Verzeichnis gefunden und das Verzeichnis mit dem Windows Defender prüfen lassen. 4000 Dateien in 12 Sekunden.
Mit dem von Dir benutzten Tool haben 20000 Dateien ca. 60 Sekunden gedauert.

Setzt man im Code Anführungszeichen, z.B. beim Setzen eines String-Werts, werden seit einiger Zeit automatisch zwei davon gesetzt, sodass man gleich den puren Text schreiben kann, ohne sich um den korrekten Abschluss (= das 2. Anführungszeichen) kümmern zu müssen. Leider werden diese nervigerweise auch gesetzt, wenn man bereits einen Text hat:


Klar, bei neuen Zeilen weiß man ja hoffentlich schon vorher, was man macht. Aber bei bestehenden Projekten passiert (mir) sowas immer wieder, dass es einfach nervt.

MS zieht in Erwägung, es anzupassen - wenn das jetzige Verhalten genügend Leute nervt: VS-Report

Es soll ja funktionieren - aber bitte richtig.

##########

Nächstes Problem bei mir: Wenn ich mehrzeiligen Code per c&p einfüge, welche zu einem automatischen Namespace-Import führt (gutes Feature!), wird die Dokumentformatierung beseitigt, also Einzüge, Abstände zwischen den Methoden. Kann man zwar mit einem Rückgängig ungeschehen machen, ist aber auch nervig. Kann das jemand bestätigen?

Der in ein WinForms-VB-Programm eingefügte C#(!)-Code ist aus stackoverflow:


##########

Update: spätestens beseitigt in Version 17.6.0 Preview 6.0

Vielleicht kann sich zu diesem Problem jemand mal die 2 Minuten Zeit nehmen und Rückmeldung geben:
Ich schließe ein Projekt im Codeeditor und lade es neu. Ich wechsle zum Designer und die Toolbox ist leer. Ich muss erst zu einem anderen Fenster wechseln (z.B. wieder in ein Codeeditortab und danach zurück zum Designer), damit die Toolboxelemente angezeigt werden.
Schließe ich hingegen das Programm, wenn das aktuelle Fenster der Designer ist, wird nach dem Wiederöffnen des Projekts im Designer sofort die volle Toolbox angezeigt.

##########

VSReport-Link von mir und von einem anderen, bei dem schon mehr Votes sind, daher besser dort voten

Und wieder was. Mal sehen, ob hier jemand Erbarmen mit mir hat und das gegenprüfen wird:
Ich habe einen SplitContainer und füge einen Button in eines der Panels, mit Anchor Überall (Left, Right, Top, Bottom).
Die SplitterDistance des SplitContainers setze ich auf den (wie ironisch) »Default«-Value 50.
Ich schließe den Designer und öffne ihn wieder. Nun haben die Panels ihre Größe geändert und der Button hat daher eine andere Größe angenommen. In der FormX.Designer.vb wird dies aber nicht übernommen/angezeigt.

Dass die ScrollPosition im SplitContainer falsch funktioniert, ist ja schon länger bekannt. Wer der Meinung ist, das sowas behoben werden sollte, darf gerne voten.

Vielleicht sollte ich den Thread umbenennen, da letzteres kein VS-Fehler, sondern ein .NET/-Frameworkfehler ist.
Oder ich lass den ganzen Thread löschen, irgendwie hab ich das Gefühl, dass das Ganze eher zu einem Blog mutiert …

PicBox-Images werden offensichtlich nicht automatisch disposed, das war das Ergebnis eines Threads von RodFromGermany
hier die Meldung an Microsoft

Ja, kann ich bestätigen. Liegt laut stackoverflow an der RTB-Version, die bei höheren Frameworks (über 4.0) eingesetzt wird. Bei 3.5 klappt die Beispiel-App.
Man kann das Programm mit einer Kompatibilitätseinstellung zum Funktionieren bringen, indem man in der app.config Änderungen vornimmt - wie bei stackoverflow beschrieben.

In .NET werden Klassennamen mit reservierten Begriffen in der FormX.Designer.VB bei Designer-Änderungen verschlimmbessert.
Beispiel: Eine BindingSource bekommt über den Designer die Zuordnung zum Typ der eigenen Klasse [Event].

Ändert man was im Designer, wird aus dem GetType([Event]) ein GetType(Event) - und somit ein Syntaxfehler. Ist in .NET-Fx-Projekten nicht so, da läuft es.

gemeldet bei Mikrosoft, dortige Zustimmung wie immer gewünscht.

@loeffel: In einem Deiner Artikel schreibst Du

Klaus Löffelmann schrieb:

The old system didn’t have an easy way to interpret more recently introduced language features. Using Roslyn, we will have the option to introduce language features like NameOf to generate more robust code, especially for data binding purposes.

Bis jetzt scheint das noch nicht zu klappen.
Designer-Code wie Button1.DataBindings.Add(New Binding(NameOf(Button1.Command), FooBindingSource, "RelayCommand", True))
oder eben andersum Button2.DataBindings.Add(New Binding("Command", FooBindingSource, NameOf(Foo.AnotherRelayCommand), True))
werden mit einer Fehlermeldung wie im Anhang quittiert.

btw: Ist eigentlich auch geplant, dass eine DGVButtonCell eine Command-Property bekommt?

Sehr interessant: Mein Bug-Report an Microsoft: Wenn man (unfreiwillig) Nothing zu einer TextBox-AutoCompleteCustomSource hinzufügt, beendet sich die App (erst) dann, wenn man irgendwann später was in die TextBox eingibt.
Reaktion von Microsoft: »Das ist kein Fehler, aber interessanter Vorschlag.«

Ah ja …