Designer-Fehler bei WinForm-Framework-Projekten unter x64

  • Allgemein

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von loeffel.

    Designer-Fehler bei WinForm-Framework-Projekten unter x64

    Moin Leute.
    Ich habe mehrere Projekte, die wegen Kommunikation mit Hardware als x86 und x64 compiliert werden müssen.
    Zum Projekt gehört ein UserControl.
    Die Form, die eine Instanz dieses UserControls hält, lässt sich unter x64 nicht im Designer öffnen,
    der Designer findet das Control nicht.
    Dieser Effekt funktioniert unter VBN.NET und unter C#.
    Die Fehlermeldung und ein einfaches Projekt, das den Effekt reproduziert, sind im Anhang.
    Handelt es sich hier um einen Fehler im Studio?

    WindowsApp2.zip
    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!
    Ich hab mir das Projekt mal heruntergeladen und geöffnet. Ich hatte zuerst das Gleiche verhalten.

    Dann habe ich das Control von ​UserControl1 zu ​UserControlTest umbennant und seitdem klappt es.
    Ob das jetzt eine größere Bedeutung hat weiß ich nicht, aber es könnte (zumindest unter VB) sein, dass er den Klassennamen nicht vom Variablennamen unterscheiden kann.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.

    siycah schrieb:

    umbennant und seitdem klappt es.
    Bei mir leider nicht.
    Bei meinen andedren Projekten tragen die UserControls sinnige Namen. ;)
    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!
    Alles gut, glaube ich dir wohl :D

    Ich kann das ja nochmal machen. ich lade hier gleich meine SLN hoch, dann kannst du es selber sehen. Uno momento, por favor.

    EDIT:
    Ich könnte mich ja gerade dafür in den Arsch beißen, dass ich es gelöscht habe. Nun macht der das auch nicht mehr.

    Stattdessen habe ich jetzt folgendes gemacht.
    Projekt neu gebaut, alle Verweise aus dem Designer Code gelöscht und das Ding neu hinzugefügt.




    WindowsApp2.zip
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.

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

    Ich hab nur das Projekt kompiliert und dann den Form2-Designer aufgerufen. Hat geklappt.
    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:

    Ich hab nur das Projekt kompiliert
    x64?
    Per default kommt AnyCPU.
    ===================
    Löscht mal die AnyCPU-Konfiguration, die kommt sonst bei mir nicht vor.
    Dann sollte es stets knallen.
    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!
    Habe den Download aus Post#1 verwendet, die Projektmappe geöffnet, in den Projekteinstellungen ZielCPU auf x64 eingestellt, das Programm kompiliert, dann den Form2-Designer geöffnet und keine Fehlermeldung bekommen, sondern das Form inkl. UserControl wurde angezeigt.
    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.
    @All
    Danke für Eure Kommentare.
    Das Problem habe ich leider auf Arbeit und hier zu Hause.
    Möglicherweise gibt es da eine Einstellung im Studio, die bei mir falsch ist. ;(
    ============

    Haudruferzappeltnoch schrieb:

    Wie löscht man sowas?
    Konfigurationsmanager => Bearbeiten => Entfernen

    -----
    der umgekehrte Weg:
    Konfigurationsmanager => Bearbeiten => Neu ...
    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!
    Frühstücksspekulatius: bei Dir Visual Studio 2019, bei den anderen VS 2022.
    Ich hab noch woanders ne 2019er Version. Mit der teste ich das mal später.
    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:

    bei Dir Visual Studio 2019, bei den anderen VS 2022.
    Jou.
    Studio 2022 funktioniert.
    Leider ist mein Chef der Meinung, dass wir kein anderes Studio benötigen.
    ====
    Ich denke, damit können wir dieses Thema beenden.
    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!
    Das Problem ist Folgendes:

    Visual Studio 2019 ist 32-Bit, Visual Studio 2022 ist 64-Bit. Das bedeutet, dass der WinForms Designer natuerlich auch in der Bitness des Host-Prozesses laeuft, also je nach Version 32-Bit oder 64-Bit. Wenn ein Projekt mit "Any" kompiliert werden kann, startet der Designer zur Entwurfszeit die entsprechend verwendeten Controls und deren Designer (und die entsprechenden "darunterliegenden" Komponenten) mit der Bitness, die der Hostprozess vorgibt. Beim Profil "Any" geheb also 32 und 64 Bit. Probleme gibt es, wenn eine Komponente oder ein Projekt zwingend 32-Bit zur Laufzeit benoetigt - beispielsweise wenn es sich um sehr alte COM-Komponenten (VB6, Win32) handelt, oder auch wenn eine Datenbank Verbindung zu Access beispielsweise auf einen 32-Bit-Hostprozess besteht.

    In diesem Fall kann Visual Studio 2022 das Form/UserControl nicht oeffnen, weil die Bitness nicht kompatibel ist.

    Wir arbeiten zur Zeit an einer weiteren Version des WinForms Out-Of-Process Desigers. Fuer .NET vs. .NET Framework gibt es ja ein aehnlich gelagertes Problem: Ein .NET Prozess (WinForms App TFM .NET 3.1 Core, .NET 5+) kann nicht in einem .NET Framework Prozess gehostet werden. Also muessen wir den "Anzeigeteil" des Designers aus dem Visual Studio Prozess nehmen ("...taking it out of the Visual Studio Process") und in einen dedizierten .NET Prozess packen - daher der Name "Out-Of-Process Designer". Und die beiden Prozesse unterhalten sich dann via JsonRPC.

    Das Problem ist jedoch, dass die Control Designer, so sie denn mehr als nur TypeConverter als Design-Time Funktionalitaet zur Verfuegung stellen, nicht mehr zum In-Prozess-Designer kompatibel sind. Das heisst, dass 32-Bit gebundene Projekte, die komplexe Control Libraries (DevExpress, Telerik, ComponentOne, etc.) mit eigener Designer Benutzeroberflaeche verwenden, nicht mehr zum Designer kompatibel sein werden.

    Dringender Rat deswegen: Modernisiert Komponenten, die 32-Bit erfordern, moeglichst schnell auf moderne Alternativen, oder migriert die komplette Anwendung so schnell wie moeglich von Framework zu .NET Core, weil alle namhaften 3rd party Control Library Vendors fuer .NET 5+ bereits ihr Produkte auf den .NET Out-Of-Prozess-Designer angepasst haben.

    Blog Post auf der .NET Blog-Seite folgt im Laufe der naechsten beiden Wochen.

    HTH!

    Klaus