Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
WPF und Standardnamespace - doppelter Root?
Ichthys
myCSharp.de - Member



Dabei seit:
Beiträge: 136

Themenstarter:

WPF und Standardnamespace - doppelter Root?

beantworten | zitieren | melden

Hallo,

ich habe anscheinend eine absolute Anfängeranfrage. Ich habe eine WPF-Anwendung mit dem Namespace "Wurzel.name3" erstellt.

Wenn ich nun das Event StartUp aboniere, um die Argumente zu erhalten,

habe ich nun das Problem, dass VS immer moniert, "App wurde in Wurzel.Wurzel nicht gefunden". Wenn ich nun manuell die erstellte App.g.cs bearbeite und aus

Wurzel.name3.App App = new Wuzel.name3.App();

App App = new App();
mache, funktioniert alles korrekt.
Warum erstellt das VS an der Stelle nicht lauffähigen Quelltext?
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15703
Herkunft: BW

beantworten | zitieren | melden

Hat nichts mit WPF zutun, sondern rein .NET.

Du scheinst hier den gleichen Bezeichner eine Klasse und in einem Namespace zu haben.
Daher kommt der doppelte Bezeichner zustande, da ansonsten die Eindeutigkeit fehlt.

Passiert prinzipiell oft, wenn man sich nicht an die Naming Guidelines der Namespaces hält ;-)
Namen von Namespaces
private Nachricht | Beiträge des Benutzers
Ichthys
myCSharp.de - Member



Dabei seit:
Beiträge: 136

Themenstarter:

beantworten | zitieren | melden

Hehehe. SO einen Anfängerfehler mache ich dann doch nicht. :-D Das einzige, was passiert, ist das Einbinden einer DLL, welche die gleiche Wurzel hat. Also Wurzel.DLL und Wurzel.App wären vorhanden.
Und das passiert bei mir bei einer frisch erstellten WPF-Anwendung, sogar ohne DLL-Einbindung.
Seltsam...
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15703
Herkunft: BW

beantworten | zitieren | melden

Naja, wenn der Name "App" mehrmals vorhanden ist, dann passiert genau das.
Ohne eindeutigen Namespace weiß der Compiler nicht, was er tun soll.

Falls es das nicht ist, dann verstehe ich vermutlich Deine aktuelle Umgebung nicht.
private Nachricht | Beiträge des Benutzers
MarsStein
myCSharp.de - Experte

Avatar #avatar-3191.gif


Dabei seit:
Beiträge: 3429
Herkunft: Trier -> München

beantworten | zitieren | melden

Hallo,

also ehrlich gesagt versteh ich es auch nicht so ganz - könnte an der Beschreibung liegen
Ich vermute, dass hier die entscheidende Information noch fehlt.

@Ichthys
Zitat
Und das passiert bei mir bei einer frisch erstellten WPF-Anwendung
kannst Du dann mal eine minimale Beispiel-Solution zippen und hochladen, die den Fehler aufweist?
Dann kann man das vielleicht nachvollziehen.

Gruß, MarsStein

Edit: und verrat uns bitte, mit welcher VS-Version Du arbeitest...
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von MarsStein am .
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
private Nachricht | Beiträge des Benutzers
Ichthys
myCSharp.de - Member



Dabei seit:
Beiträge: 136

Themenstarter:

beantworten | zitieren | melden

So, jetzt noch mal genauer:
Meine Aussage, dass es ohne Einbindung der DLL bereits passierte, muss revidiert werden. Ich habe die DLL nachträglich entfernt und da passierte der Fehler immer noch. Nach einem Aufräumen des Projekts und der Neugenerierung trat der Fehler nicht mehr auf.
Also ist die DLL dafür verantwortlich.

Zur Umgebung: Visual Studio 2017 + .net 4.6.1

Ich habe eine Anwendung mit dem Namespace veratel.v3.
Dazu binde ich eine DLL mit dem Namespace veratel.veraFramework ein.
Aus meiner Sicht gibt es da keine Überschneidungen. Allerdings sieht das VS das anders. IntelliSense schlägt z.B. dann immer veratel.veratel vor, wenn ich veratel eingebe.
Wo kann der Fehler liegen? Es muss doch sowas möglich sein, dass eine DLL und eine Anwendung sich den gleichen Wurzelnamensraum "veratel" teilen und anschließend anders weitergehen.

Das VS zeigt folgende Fehlermeldung an:
Fehler
CS0234 Der Typ- oder Namespacename "v3" ist im Namespace "veratel.veratel" nicht vorhanden. (Möglicherweise fehlt ein Assemblyverweis.) veratel v3 C:\Users\Name\Documents\GitHub\veratel v3\obj\Debug\App.g.cs
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Ichthys am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15703
Herkunft: BW

beantworten | zitieren | melden

In meinen Augen liegt das eben an dem Fehler, wie dort mit den Namespaces umgegangen ist.

Ich kenn da auch ein Beispiel aus der Open Source Szene: GenFu.
Der Namespace heisst GenFu und die Klasse heisst GenFu: https://github.com/MisterJames/GenFu/blob/master/src/GenFu/GenFu.cs

Da für VisualStudio (bzw. der Compiler) nun nicht eindeutug ist, ob "GenFu" allein die Klasse oder der Namespace ist, muss der vollständige Name verwendet werden:

int rand = GenFu.GenFu.Random.Next(9, 99);
Siehe auch: https://github.com/BenjaminAbt/2018-Talks-ModernApiDevelopment/blob/master/src/Common/Database/Repositories/InMemory/InMemoryDataContext.cs

Deine Fehlermeldung ohne Beispielcode macht wenig Sinn.
Denn woher "veratel.veratel" kommt, das sehen wir hier wieder nicht.
Zitat
Es muss doch sowas möglich sein, dass eine DLL und eine Anwendung sich den gleichen Wurzelnamensraum "veratel" teilen und anschließend anders weitergehen.
Prinzipiell funktioniert das, wenn man Namespaces so verwendet, wie sie gedacht sind.
Aber natürlich kann es durch eine falsche Nutzung von Namespaces zu Inkompatibilitäten von DLLs kommen; so ists einfach.
Das heisst aber nicht, dass man sie nicht gemeinsam nutzen könnte; aber man muss dann eben den vollständigen Namespace angeben.

Aber wer eine Version in nen Namespace packt, den kümmert vermutlich die restlichen Guidelines auch nicht :-)
private Nachricht | Beiträge des Benutzers