(NET 7, ne doch nicht) Application.Designer kann kein Windows Forms?

  • VB.NET
  • .NET 5–6

Es gibt 18 Antworten in diesem Thema. Der letzte Beitrag () ist von Haudruferzappeltnoch.

    (NET 7, ne doch nicht) Application.Designer kann kein Windows Forms?

    Hallo,

    habe ein NET 7 Projekt erstellt. Kann dieses allerdings nicht starten, im Application.Designer.vb wird in diesem Code

    VB.NET-Quellcode

    1. Protected Overrides Sub OnCreateMainForm()
    2. Me.MainForm = Form1
    3. End Sub
    gemeldet, "Form1 ist ein Klassentyp und kann nicht als Ausdruck verwendet werden."
    Das ist ja auch richtig, aber sowas hat das Framework ja nie interessiert.

    Also schreib ich ein New davor, dann startet es.
    Allerdings steht im Designer auch das hier:
    'HINWEIS: Diese Datei wird automatisch generiert und darf nicht direkt bearbeitet werden. Wenn Sie Änderungen vornehmen möchten
    ' oder in dieser Datei Buildfehler auftreten, wechseln Sie zum Projekt-Designer.
    ' (Wechseln Sie dazu zu den Projekteigenschaften, oder doppelklicken Sie auf den Knoten "Mein Projekt" im
    ' Projektmappen-Explorer). Nehmen Sie auf der Registerkarte "Anwendung" entsprechende Änderungen vor.
    Also das kanns wohl nicht sein. In den Projekteingenschaften weiß ich allerdings nicht, was ich suche. Dort Änderungen zu tätigen erzeugt den Fehler erneut.

    Viele Grüße

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    Haudruferzappeltnoch schrieb:

    VB.NET-Quellcode

    1. Me.MainForm = Form1
    machst Du

    VB.NET-Quellcode

    1. Me.MainForm = New Form1
    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!

    @VB1963 Diese Fehleremeldung zielt genau auf das New.
    Mit NET 7 hab ich noch nicht gespielt.
    Ist da jemand (der Designer z.B.) der Meinung, da eine Sch Mist Kompatibilitätsinstanz einzutragen aber nicht auswerten zu können?
    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!

    wenn sich das bestätigt, dass der net.7 ApplicationDesigner Code erzeugt, der nicht kompiliert, ist das wohl eine Kinderkrankheit.
    Man kann sowas reporten (hab aber vergessen, wo genau). Ausserdem denkich, das wird @loeffel interessieren, weil derselbe steckt glaub höchstpersönlich drin inne .Net-Entwicklung von MS.

    Bin einige Monate nach dem Umstieg auf .Net 7 zu Jetbrains Rider gewechselt weil VS extrem viele Bugs und Probleme mit dem Designer hatte. Das Zünglein an der Wage war, das Fehler nicht mehr angezeigt wurden… VS ist somit weitestgehend unbrauchbar geworden für mich und wird nur noch für das nötigste gestartet. (Grüße an @loeffel). Würde mich also nicht wundern wenn hier (Thema des Threads) der Wurm drin wäre.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Wäre ja sinnvoll, wenn an dieser Stelle dann endlich mal mit korrekten Instanzen gearbeitet wird. Dieses Pseudo-VB-Coding war mir schon immer ein Dorn im Auge. Nur sollte der Designer es dann halt auch können. :D

    Da hilft wohl tatsächlich nur ein Bug Report. Dennoch seltsam, dass sowas in Production passieren kann.

    Viele Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Jou, diese statischen Instanzen durch Zauberei sind wirklich Mist. Die erschweren manch einem das Leben, die glauben die können Programmieren und probieren dann C# aus und denken sich: Was ist das für ein Mist? Weils nicht klappt wie in VB. Dabei ist IMO C# die schönere Sprache, ich mag den C-Syntax. Schade das wegen sowas einige die Eleganz von C# deswegen nicht wirklich kennenlernen, weil sie dann bei dem bleiben wo ihr Code läuft.

    Ich hatte zwar schon in Kindertagen kontakt zu BASIC, ja zu der Zeit als man den Inhalt des Arbeitsspeichers noch lesbar auf ein DIN A4 Blatt drucken konnte, konnte auch schon selbst Code schreiben, aber nichts wirkliches. Richtig fing ich mit VB.Net an, war damals glaub ich das 2005er Studio. Dieser statische "Form1" zugriff, wie auch Option Strict Off als default haben mir das lernen anderer Sprachen erschwert. Ich hab mich so sehr dran gewöhnt an diesen Mist, ich frage mich heute, warum ich Laufzeitfehler in Kauf nahm und die dann immer mit einem "Code-Pflaster" gepatched hab. Das hätte ich einfacher haben können(viele andere auch), allein wenn Option Strict default auf On gewesen wäre. Dann wäre mir Java und C++ leichter gefallen, C# war dann zum Glück kein Problem mehr.

    Ich hoffe loeffel liest sich das durch, EDR hat ihn hier im Thread ja bereits angepingt. So oft wie ich hier Option Strict Off Code sehe und mit Option Stric On wäre die Ursache des Problems sofort erkennbar , da denke ich mir auf jeden Fall: Warum tut Microsoft das seinen Usern an?
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „DTF“ ()

    Hallo alle,

    ich habe gerade versuchsweise ein neues VB Projekt mit VS 2022 und .NET 7 erstellt, und konnte es problemlos erstellen, bearbeiten und auch starten.
    Um so mehr bin ich jetzt daran interessiert, wo es bei euch hakt.

    Ich muesste wissen:
    a) Verwendet ihr die deutsche oder englische Version von VS?
    b) Welche Version verwendet ihr genau (Help/Hilfe -- About Visual Studio/Ueber Visual Studio).

    Zum Hintergrund vom Start-Form:
    Die Zeile Me.MainForm = Form1 ist korrekt.
    Da sich der code im My-Namespace befindet, is Form1 in diesem Fall kein Typ sondern eine Eigenschaft vom Type Form am MyForms object (see screenshot).

    Die Frage, die sich mir stellt:
    Existiert die Namespace definition im File?

    VB.NET-Quellcode

    1. '------------------------------------------------------------------------------
    2. ' <auto-generated>
    3. ' This code was generated by a tool.
    4. ' Runtime Version:4.0.30319.42000
    5. '
    6. ' Changes to this file may cause incorrect behavior and will be lost if
    7. ' the code is regenerated.
    8. ' </auto-generated>
    9. '------------------------------------------------------------------------------
    11. Option Strict On
    12. Option Explicit On
    14. Namespace My
    16. 'NOTE: This file is auto-generated; do not modify it directly. To make changes,
    17. ' or if you encounter build errors in this file, go to the Project Designer
    18. ' (go to Project Properties or double-click the My Project node in
    19. ' Solution Explorer), and make changes on the Application tab.
    20. '
    21. Partial Friend Class MyApplication
    23. <Global.System.Diagnostics.DebuggerStepThroughAttribute()>
    24. Public Sub New()
    25. MyBase.New(Global.Microsoft.VisualBasic.ApplicationServices.AuthenticationMode.Windows)
    26. Me.IsSingleInstance = False
    27. Me.EnableVisualStyles = True
    28. Me.SaveMySettingsOnExit = True
    29. Me.ShutDownStyle = Global.Microsoft.VisualBasic.ApplicationServices.ShutdownMode.AfterMainFormCloses
    30. End Sub
    32. <Global.System.Diagnostics.DebuggerStepThroughAttribute()>
    33. Protected Overrides Sub OnCreateMainForm()
    34. Me.MainForm = Form1
    35. End Sub
    36. End Class
    37. End Namespace


    Ich waere sehr dankbar, falls jemand eine "fehlerhaftes" VB Projekt mit seiner aktuellen Version erstellen, zippen, und mir auf OneDrive, DropBox, etc. zur Verfuegung stellen koennte:
    Link bitte an klaus punkt loeffelmann at microsoft punkt com.

    Vielen, vielen Dank!!

    PS:

    Dennoch seltsam, dass sowas in Production passieren kann.


    Sorry, zur Zeit arbeiten wir (meine Kollegin Melissa vom Project System Team) und ich am Application Framework fuer VB. Wir haben ein eigenes Test Team, aber ja, uns rutschen Sachen durch. Das ist dann aergerlich, aber wir bemuehen uns so schnell wie moeglich, Dinge zu fixen.

    Man kann sowas reporten (hab aber vergessen, wo genau). Ausserdem denkich, das wird @loeffel interessieren, weil derselbe steckt glaub höchstpersönlich drin inne .Net-Entwicklung von MS.

    Yepp. Wenn ihr in Visual Studio oben rechts den Send Feedback Butten klickt, und bei allen VB-relevanten Sachen "WinForms" mit in den Titel schreibt, bekommen wir die Tickets vergleichsweise schnell. Alternativ koennt ihr auch Fehler (auch fuer den Designer!) im WinForms GitHub Repo reporten. Falls ihr euch nicht ausreichend trittsicher in Englisch fuehlt, nutzt bing translate, google translate ODER deepl.com fuer die Uebersetzung - das funktioniert immer super gut.
    Bilder

    • Screenshot VB AppFramework.jpg

      336,88 kB, 1.979×1.087, 48 mal angesehen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „loeffel“ ()

    Nutze Visual Studio 2022 in deutsch. Version 17.7.3. Namespace My ist auch korrekt vorhanden.

    Habe beim Anfertigen eines Minimalprogramms den Fehler gefunden, es ist eigentlich schon durch mich verursacht, fiel mir aber gar nicht so leicht auf.

    VB.NET-Quellcode

    1. Friend Class Form1
    2. Friend Sub New()
    3. ' Dieser Aufruf ist für den Designer erforderlich.
    4. InitializeComponent()
    5. End Sub
    6. End Class
    Beim Einfügen einer eigenen Sub New im Form1 Code, die durch Friend limitert wird, wird aus dem schwarzen Form1 in Me.MainForm = Form1 ein blaues Form1. Irgendwo nehme ich ihm damit also den Zugriff weg. Mach ich die Sub New Public dann gehts, (wobei die Form1 selbst immer noch Friend ist, was ja an sich alles in der Klasse auch runterstuft.)
    Das passiert aber auch im 4.8 Framework also anscheinend mein Fehler, sry

    VB.NET-Quellcode

    1. Friend Class Form1
    2. Public Sub New()
    3. ' Dieser Aufruf ist für den Designer erforderlich.
    4. InitializeComponent()
    5. End Sub
    6. End Class


    Aber: Me.MainForm = New Form1 geht halt auch bei Friend Sub New, deswegen verstehe ich auch gar nicht recht was passiert.

    Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    loeffel schrieb:

    Da sich der code im My-Namespace befindet, is Form1 in diesem Fall kein Typ sondern eine Eigenschaft vom Type Form am MyForms object
    Ja genau, das war vielleicht von uns zuvor etwas schlecht ausgedrückt. Damit der Code kompiliert, muss es sich bei Form1 hier im Kontext natürlich um eine existente Property handeln, die eine bestehende, vordefinierte Instanz hält (sonst würde ja eben genau der Fehler vom TE auftreten, weil er es für einen Klassenausdruck hält). Was hier eher gemeint war, wäre die (imo durchaus sinnvolle) Anpassung, dass man hier explizit auch New schreiben müsste, um eine Instanz zu erstellen statt diese magisch zu bekommen. Analog dann zu Form1.Show usw. Die initiale Lösung vom TE sollte also idealerweise so der Standard sein. Ist ne coole Idee, dass man es vom My-Namespace geschenkt bekommt, aber konzeptionell empfinde ich dies eher als inkorrekt. Analog würde sowas in C# nicht gehen, wie @DTF erwähnt hat.

    Ist aber tatsächlich ein OffTopic-Thema und nur meine persönliche Meinung. Hier sollte es ja primär um die Fehlerbehebung gehen. ;)

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Haudruferzappeltnoch schrieb:

    Me.MainForm = New Form1 geht halt auch bei Friend Sub New
    Der Konstruktor kann den Zugriff nicht über die Klasseneinschränkung hinaus erweitern. Ob Du also in einer Friend Class einen Public New-Konstruktor oder einen Friend New-Konstruktor nimmst, ist egal.
    Bzgl.

    Haudruferzappeltnoch schrieb:

    Irgendwo nehme ich ihm damit also den Zugriff weg
    Das nutze ich, um Form1.Show zu verhindern.
    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 Oja, das ist was ich tue. Es war echt ein blöder Zufall, dass dies bei einem NET 7 Projekt aufgefallen ist. Vorher habe ich das wohl nie gemacht.

    Im My Namespace muss dann aber doch irgendwo die New aufgerufen werden, aber es wird halt nirgendwo angezeigt, dass das das Problem ist. Das Ganze ist eher eine Schlusfolgerung aus den Beobachtungen.

    Ist ne coole Idee, dass man es vom My-Namespace geschenkt bekommt, aber konzeptionell empfinde ich dies eher als inkorrekt


    Ihr muesst natuerlich VB im historischen Kontext betrachten. Auch wenn es viele inkompatibilitaeten zu VB6 gab, haben wir damals schon darauf geachtet, dass moeglichst viel gleich blieb (oder man moeglichst wenig aendern musste, obschon das .NET Framework viele Aenderungen einfach hat erforderlich werden lassen). Und Default Form Instances gehoerten zu VB6, und deswegen auch zu VB.NET.

    Warum tut Microsoft das seinen Usern an?

    Weil uns dieselben User die Hoelle heiss machen wuerden, wenn wir Option Explicit, Option Strict und Option Infer NICHT haetten. Wir haben mal versucht, Option Strict default zu machen - die Reaktionen darauf waren GAR nicht lustig. Ich halte es halt so: C# ist C# und VB ist VB. Das sind keine leichten Sprachgeschmacksrichtungen, das sind Sprachen fuer zwei voellig unterchiedliche Zielgruppen. Deswegen sind wir auch von der Co-Evolution abgekommen, weil es im Grunde keinen Sinn macht, zwei Sprachen mit den exakt gleichen Features auszustatten. Sonst hast du am Ende nen C# nur ohne Semicolon am Ende und mit Function und Sub. Das ergibt keinen Sinn.

    Analog würde sowas in C# nicht gehen, wie @DTF erwähnt hat.


    :)

    C#-Quellcode

    1. using System;
    3. using static MyForms;
    5. public class form1
    6. {
    7. public void Show()
    8. {
    9. Console.WriteLine("Showing Form1");
    10. }
    11. }
    13. public class form2
    14. {
    15. public void Show()
    16. {
    17. Console.WriteLine("Showing Form2");
    18. }
    19. }
    21. public static class MyForms
    22. {
    23. private static form1 _form1Instance;
    24. private static form2 _form2Instance;
    26. public static form1 Form1
    27. {
    28. get
    29. {
    30. if (_form1Instance == null)
    31. {
    32. _form1Instance = new form1();
    33. }
    35. return _form1Instance;
    36. }
    37. }
    39. public static form2 Form2
    40. {
    41. get
    42. {
    43. if (_form2Instance == null)
    44. {
    45. _form2Instance = new form2();
    46. }
    48. return _form2Instance;
    49. }
    50. }
    51. }
    53. class Program
    54. {
    55. // Using static to bring static members into scope
    56. static void Main(string[] args)
    57. {
    58. // Due to the using static directive, we can directly use Form1 and Form2
    59. Form1.Show();
    60. Form2.Show();
    61. }
    62. }

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „loeffel“ ()

    loeffel schrieb:

    die Reaktionen darauf waren GAR nicht lustig.


    Das kann ich mir sogar vorstellen, viele müssten ihren Code ändern oder es abschalten. Ich hätte das versucht durchzusetzen, einfach default auf On gemacht, aber in der ToolBar einen Button zum umschalten hinzugefügt. Beim erstmaligen deaktivieren, eine MessageBox anzeigen, warum das besser ist auf On zu haben. Bei gemecker auf die Vorteile von OS-On verwiesen, sowie auch auf den sehr leicht erreichbaren Button zum umschalten.

    Aber wo du recht hast, hast du recht. VB ist VB und C# ist C#.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Also klar kann man in C# eine analoge Implementierung dafür bauen. Ist ja in VB.NET auch nichts magisches - genau dasselbe passiert im My-Namespace halt schon vordefiniert. Was ich meinte ist, dass in C# sowas nicht standardmäßig unterstützt wird (es würde nicht einfach so from scratch gehen wie dann in VB.NET) und daher Leute grade beim Umstieg verwirrt.

    Ich verstehe aber das Argument, dass es zwei verschiedene Sprachen sind, die konzeptionell auf andere Zielgruppen abzielen. Man ist glaub nur geneigt, beide als stark analog anzusehen, weil sie auf .NET basieren und nahezu alles 1:1 mappable ist, wodurch man im C#-Kontext solche Konstrukte dann kritischer ansieht. Aber nun genug OT dazu. :D

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    @Haudruferzappeltnoch: Dein Post#10 bringt mich doch ins Grundsatz-Verständnis-Grübeln. Friend Class + Public Sub New funktionieren, Friend Class + Friend Sub New hingegen nicht. Offensichtlich ein Punkt, der seit Jahren falsch in meinem Verständnis hinterlegt ist. Wenn die Klasse dank Friend nicht über das Assembly hinaus sichtbar ist, warum kann es dann der Zugriffsmodifikator des Konstruktors rausreißen, dass das eine funktioniert und das andere nicht? Ist das jetzt eine Besonderheit des Unterbaus oder ein grundsätzliches funktionales Missverständnis meinerseits?
    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.

    Das hat was mit Generics und dem New() Constraint zu tun (sorry, ich schreibe hier jetzt Denglish, weil ich die deutschen Begriffe nicht mehr kenne).
    Grundsaetlich hast du Recht, dass die Access Modifier mit Internal/Internal und Internal/Public aufs Gleiche hinauslaufen. Der einzige Unterschied (von Reflection mal abgesehen) ist, wenn du eine generischen Typ definierst, der den New Constraint vorschreibt. _Dann_ spielt der Unterschied internal/public eine Rolle.

    Beim VB AppFramework ist es so, dass die ganzen My-Support-Klassen beim Kompilieren durch den VB Roslyn Compiler direkt injected werden. Das geschieht eben auf Basis von Generics: Die Stelle, an der das passiert (oder vielmehr: mit der das passiert), kannst du dir hier anschauen, ich denke, dann wird der Zusammenhang klarer:

    github.com/dotnet/roslyn/blob/…/VbMyTemplateText.vb#L178

    HTH,

    Klaus

    Ich wüsste noch ein anderes Beispiel, wo das einen Unterschied macht. Bei Serialisierung von Klassen.
    Public Properties aus einer Friend Klasse kann man serialisieren, aber Friend Properties nicht, wobei das mache ich natürlich mit schon vorhandenen Tools, deswegen vermute ich funktionieren diese genauso.

Facebook
Telefonspende