Kannst Du mal bitte das Projekt ohne bin-, obj-, .vs- und .git-Ordner und gezippt über [+ Erweiterte Antwort] hochladen? Vielleicht finden wir so das Problem und eine Lösung.

Ja wurde es, hier ist alles dokumentiert, was dazu bekannt ist. Es fängt erst ein bisschen wirr an, kommt der Sache aber auf den Grund.
Für das Problem, das jener Thread beschreibt ist auch bereits ein Fix erfolgt mit VS 17.5! Wenn du diese oder eine höhere Version hast, dann musst ggf. prüfen ob bei dir nicht vielleicht doch andere Bedingungen vorliegen.

Das ist richtig, das habe ich auch dazu geschrieben. Ich habe allerdings noch nicht in dein Beispielprojekt reingucken können. Ich denke heute Abend. Oder jemand anders schaut vorher drüber.

In der Zwischenzeit kannst du ja vielleicht schon Unterschiede feststellen. Der Thread enthält auch ein Beispielprojekt. Es ist ja auch nicht ausgeschlossen, dass das Problem aus jenem Thread nun wieder "kaputt gefixt" wurde.
Einen Unterschied sehe ich aber so schon, bei mir haben andere Klassen nicht funktioniert, bei dir funktioniert das DataSet selbst nicht.

-Edit-
@woofy49 Also ich kann das Problem nachstellen. Man muss nur ein frisches NET 6 Projekt machen und versuchen ein DataSet auf Form zu kriegen.
Ich war damals schon der Meinung, dass das Problem in dem alten Thread nicht gelöst sondern umgangen wurde. Erstaunlicherweise konnte ich DataSets noch zu den Zeiten 17.5 in NET 6 nutzen. Aber jetzt scheint das nicht mehr zu gehen und zwar aus demselben Grund wie in dem anderen Thread nämlich Namespace-Salat.

Ich kann mir gut vorstellen, dass @loeffel das interessiert, da er sich auch maßgeblich mit dem ersten Problem beschäftigt hat.
Es ist schon ein Jahr her, damals schrieb er, man sucht nach DataSet-Problemen.
Dieses Spezielle springt einen allerdings etwas sehr auffällig an.

Ich denke mit einem DGV hat das nichts zu tun. Bei mir funktioniert das DataSet als Form-Komponente ganz allgemein in NET 6 nicht.

Wäre nett, wenn das noch wer bestätigen oder noch besser bei sich verneinen kann.

Ich lese aktiv mit seit heute, ja!

Ist das bei euch ein VB-only Problem, oder ist C# ebenfalls betroffen?

Wenn es bis 17.5.3 funktioniert hat, dann wird es eine Regression sein, die wir bei der Umstellung der Codegenerierung von CodeModel auf Roslyn verursacht haben. Es gibt gerade bei VB noch einige andere Dinge, die wir fuer 17.9 Preview 3 angehen.

Werde mir es genauer anschauen und mich dann melden.

Da sagst du was. Nein, Bei C# besteht dieses Problem nicht.

Hier die Gegenüberstellung zweier frischer Projekte (c#/vb) nach dem eine DataSet-Komponente ins Projekt eingefügt wurde:

Dauert keine Minute zum Nachstellen.

Wenn man kompiliert und das DataSet aufs Form zieht, dann wird es im Designer als WinFormsApp1.WinFormsApp1.DataSet1 deklariert.
Und das kann er nicht finden.

Zu 17.5:
Nach meinem (wirklich beschränkten!) Verständnis ist es keine Regression, denn dieser Namespace existierte schon vor VS 17.5. Und das wurde in 17.5 auch nicht behoben; dort wurde die Deklaration von projektinternen Klassen im Forms-Designer umgebaut und das ist auch heute noch gültig. Wo WinFormsApp1.MyLittleClass stand, steht nur noch MyLittleClass. Dadurch werden projektinterne Klasse nicht mehr durch den extra Namespace verwirrt
Dieser Namespace wird aufgrund von Namensgleichheit nicht richtig aufgelöst im Designer. Bei MyLittleClass hat vor 17.5 verhindert, dass sie erkannt werden. Bei DataSet1 verhindert er nun das sie erkannt wird.
Wobei nach der Logik WinFormsApp1.DataSet1 da nun stehen muss, also genauso wie eine Projektklasse vor 17.5 im Designer angegeben wurde. Damals habe ich das alles noch nicht überblickt, aber vielleicht ist dieser Fehler auch durch den Fix in 17.5 entstanden.
Fakt ist aber: Ohne den Namespace WinFormsApp1.WinFormsApp1 gibt es keine Probleme weder mit DataSet noch mit projektinternen Klassen (siehe C#).

Anbei auch nochmal das Minimal-Beispiel im aktiven Fehlerzustand.

Hey, sorry, dass es etwas laenger gedauert hat.

Ich denke momentan vorsichtig, dass das Problem nichts mit dem WinForms Designer zu tun hat.
Unter .NET und im Gegensatz zu .NET Framework generiert das DataSet-Generator-Tool eine Namespace-Anweisung, die es nicht generieren duerfte, bzw. es koennte sie generieren, wenn es dem Namespace-Namen ein `Global.` voranstellen wuerde. Und das ist das eigentliche Problem. Denn wenn deine Anwendung "DsDemo" heisst, dann moechtest du wahrscheinlich, dass sich deine DataSets im Namespace "DsDemo" und nicht im Namespace "DsDemo.DsDemo" befinden.

Welche Moeglichkeiten hasst du als Woerkaround?

* Wenn dich die doppelten Namespacenamen nicht stoeren, kannst du sie im CodeBehind-File importieren. Die Namespace-Imports im Code-Behind-File bleiben naemlich immer erhalten - lediglich alles was in `InitializeComponent` steht, wird bei jedem Designer-Flush neu generiert. Also...

```
Imports testmitXML.testmitXML

<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()>
Partial Class Form1
Inherits System.Windows.Forms.Form
```

...dann laesst du den Typnamen ohne Namespace stehen, und beim naechsten Roundtrip kann der Designer dann beim Simplifying des Codes auf die Imports-Anweisung zurueckgreifen, und braucht keine vollqualifizierten Typnamen zu emitten.

* Oder du trickst den DataSet-Generator aus. Er sollte ja eigentlich ohnehin keine Namespace-Anweisung generieren - tut das aber. Wir muessen ihne also zwingen, eine zu generieren, die passt. Wenn du die DataSet-Datei im Solution-Explorer selektierst, siehst du im Property Window eine Eigenschaft namens Custom Tool Namespace. Dort muessten wir nun einen vollstaendigen Pfad eintragen, also einen, der mit `Global` beginnt. Das geht aber nicht einfach, da die Zeichenkette `Global` in ein CodeDOM Objekt umgewandelt wird, und damit der Basic-Codegenerator dann einen Identifier generieren kann, der nicht mit dem Global-VB-Schluesselwort kollidiert, packt er das Global automatisch in eckige Klammern - und genau das wollen wir ja nicht. Aber wenn wir unserem Voll-Pfad-Namespace nicht `Global` sondern `Global[space]` voranstellen, packt CodeDOM den Identifier-String NICHT in eckige Klammern, und der VB-Compiler ist aber ausreichend verzeihend, dass er das zusaetliche Leerzeichen ignoriert. Also `Global .einxmlTest` sollte dann funktionieren: In diesem Fall generiert das Tool die Zeile `Namespace global .einxmlTest`, was zwar nicht schoen ausschaut, sich aber problemlos kompilieren laesst.

Hope that helps!

Gruss aus Redmond,

Klaus

loeffel schrieb:

Oder du trickst den DataSet-Generator aus. Er sollte ja eigentlich ohnehin keine Namespace-Anweisung generieren - tut das aber. Wir muessen ihne also zwingen, eine zu generieren, die passt. Wenn du die DataSet-Datei im Solution-Explorer selektierst, siehst du im Property Window eine Eigenschaft namens Custom Tool Namespace. Dort muessten wir nun einen vollstaendigen Pfad eintragen, also einen, der mit `Global` beginnt

Funktioniert einwandfrei. (Global .ProjektNamespaceName)
Und adressiert das Problem absolut an der richtigen Stelle meiner Meinung nach. Ist übrigens auch die richtige Abhilfe für das Problem das in 17.5 anderweitig behoben wurde.
Das ist auch eine Lösung, die mal wieder zeigt, dass es eigentlich ein Problem von mangelndem Verständnis der User ist. Aber das scheint ja wirklich kaum einer gewusst zu haben!