Bezeichnung für Namespace und Klasse / Problem bei Gleichheit

Aber wenn Du sagst, dass der Objektbrowser nicht alles anzeigt und da unter den anderen Namespaces vielleicht doch noch der 'System' versteckt ist... dann liege ich wohl doch falsch und kann mich auf die Werkzeuge, die MS liefert, nicht verlassen (und auf den Reflector auch nicht).

Ich klär die Sache mal auf:

Der Objektexplorer zeigt nur Klassen an, die public sind. Der Reflector zeigt alles an! Egal ob private oder internal. Warum MS das so macht? Ganz einfach, die wollen sich 3423 usings ersparen im Code.
Ich mach das ebenfalls so, das mein "Hauptnamespace" in anderen Assemblies erweitert wird, aber diese Erweiterungen internal sind. So brauche ich nicht immer zig usings einbinden, nur weil mal 1-2 Helferklassen drin habe, die ich in der eigentlichen Assembly benötige, da ich ja bereits den "Hauptnamespace" eingebunden habe.
Das erspart ein eine Menge Tipparbeit. Aber wenn man das so macht, muss man sich von vorneherein über die Typennamen einig sein. Sobald ein Typ 2x auftaucht, tritt dein eigentliches Problem auf was du gerade hast.
Bei mir wird sowas nie passieren, weil es einfach nicht vorkommt, das ich Klassen habe, die mehrmals auftauchen. Ich hab hier knapp 30 Assemblies liegen und nicht eine Klasse hat den selben Namen.
Es sind in den 30 Assemblies ca. 250 Typen drin. Also Klassen, Enums, Delegates, Interfaces. Halt alles was man in einem namespace so deklarieren kann.

Deswegen verstehe ich irgendwie dein Problem nicht so wirklich...

[Edit]
Also verstehen tue ich es schon. Nur irgendwie weis ich nicht genau was du willst. Du willst ja verschiedene einzelne Controls entwickeln und diese einzelnd weitergeben.

Kannst du die Controls nicht logisch Gruppieren, so wie
xxx.Gui.Charting
xxx.Gui.Reports
(nur Beispiele)

Ich klär die Sache mal auf:
[...]

Okay, das leuchtet mir ein. Vielen Dank für die ausführliche Erklärung 🙂

Sobald ein Typ 2x auftaucht, tritt dein eigentliches Problem auf was du gerade hast.

Naja, aktuell habe ich das Problem ja nicht; ich habe nur ein bissel weitergedacht, was mal passieren könnte. Und da war ich halt bei dem Scenario, dass ich ich 5000 Controls entwickelt habe - nee, mal im Ernst. Ich wollte halt alle Eventualitäten im Vorfeld abklären.

Vielleicht muss ich mich tatsächlich fügen, und dafür Sorge tragen, dass nichts doppelt auftreten kann; auch wenn es mir jetzt gerade nicht so gefällt.

Wenn aber tagelang drei Leute auf einen einreden - irgendwann wird man schwach 😉

Kannst du die Controls nicht logisch Gruppieren, so wie
xxx.Gui.Charting
xxx.Gui.Reports
(nur Beispiele)

Würde irgendwann u.U. den gleichen Effekt haben, wenn (auch nur ein Beispiel) ich nur Controls entwickle, die sich dem Namespace xxx.Gui.Reports zuordnen lassen 😉

Aber egal. Ich werde mal noch ein bissel drüber nachdenken.

Danke nochmal an alle, die dieser Diskussion standgehalten haben 😉

Und ich hoffe, dass niemand böse auf mich ist, dass ich vielleicht ein wenig schwerer zu überzeugen bin X(

noch als kleinen tipp. wenn du dir .net charing ansiehst, dann stellst du fest, das die ungefähr 300 controls für winforms anbeiten. auch die haben es hinbekommen.

ps: objectbrowser ist sowieso der letzte sch... den benutze ich aus prinzip nie.

@JAck30lena
Danke, werde es mir merken 😉

*********

Abschließend möchte ich noch aus einem Microsoft-Support-Artikel zitieren, den ich gerade gefunden habe, und der sich mit genau meinem Problem beschäftigt.

Angeboten werden zwei Lösungsansätze; man beachte den Zweiten 😉

SYMPTOMS
When you work in Microsoft BizTalk Server 2004 with orchestration in Microsoft Visual Studio .NET 2003, and when you have assemblies that share a name in a namespace in your Solution, only one of the namespace and assembly combinations may be available for selection.

Back to the top
CAUSE
This issue occurs when you reference multiple assemblies that share the same namespace. In this situation, the first assembly that is added added to the solution appears but additional assemblies that contain the same name in the namespace may not be available for selection. If two assemblies share a class name in a common namespace, you can only reference the first assembly with that class name because Visual Studio .NET 2003 cannot determine the assembly that you want. For example, this situation may occur if you follow these steps:

1. You create a new solution in Visual Studio .NET 2003.
2. You add a minimum of two projects with a common namespace and a common class name, and then include you the two projects in the solution by reference.
3. You add a BizTalk Server 2004 project to the solution, and then you add an orchestration to the project.
   In this situation, if you declare a variable and then select Variable type, only the first assembly that you add to the project appears in the list of available assemblies.

Back to the top
RESOLUTION
To resolve this issue, use one of the following methods:
• Rename one of your classes so that each class has a unique name.
• Create a secondary namespace before each class name Quelle

ja, das beschreibt das Problem wenn Du 2 Klassen mit dem Namen NumberTextBox hast. ähm... dann hast Du aber sowieso ein anderes auch noch.

Ich habe mir das jetzt alles durchgelesen, puh da steht viel und ja ihr habt einander vorbei geredet.

Fazit:
Ich habe mir auch mal so ne ControlColletion gebastelt (TextBox, NumberBox, ComboBox, DateTimepicker, etc.) alle waren im Namespace (in diesem Fall = Assembly) oRRoSoft.Windows.Forms
wenn Du wirklich jedes einzelne Control in eigene Assembly auslager willst hat das doch meiner Ansicht nach sehr wenig mit dem Namespace zu tun
Klasse: TextBox
Namespace: oRRoSoft.Windows.Forms
Assembly: oRRoSoft.Windows.Forms.TextBox.dll
und soweit ich weis regt sich dann niemand auf

Hallo und danke für Deinen Beitrag,

Ich habe mir das jetzt alles durchgelesen, puh da steht viel und ja ihr habt einander vorbei geredet.

lies aber lieber doch 😉

Das was Du vorschlägst, haben die anderen auch schon alle gesagt 😉

ups, dann habe ich offensichtlich "vorbeigelesen"
sry

Hallo s-sharp,

Create a secondary namespace before each class name

also erstens ist das ein Rat für den Fall, dass ein Konflikt schon aufgetreten ist. Zweitens bezieht sich der Rat nur auf die beiden Klassen, die den Konflikt auslösen. Drittens steht da selbst dann ausdrücklich nicht, dass du die secondary namespace wie die Klassen nennen sollst. Und viertens ist dieser Rat eine in meine Augen nachrangige Alternative für den Fall, dass man die Klassen nicht umbenennen kann oder will. Insgesamt ist es nicht das geringste Argument für deine Position.

Aber du kannst gerne für jede Klasse einen Namespace machen und diese so nennen wie die Klasse. Wer deine Klassen benutzt und die ganzen Usings braucht, der denkt dann halt, dass da ein Anfänger und/oder Dilettant am Werk war. Wenn du dich hier von unseren Argumenten sowenig beeindrucken lässt, vermute ich, dass dir auch das nichts ausmachen wird. 🙂

Da du ja aber eine Lösung haben willst, mit der du in fünf oder mehr Jahren noch glücklich bisst, würde ich dir trotzdem dazu raten, dich auf wenige (große) Namespaces zu beschränken und keinesfalls Klassennamen als Namespace-Namen zu verwenden.

herbivore

Hallo herbivore,

Vielleicht muss ich mich tatsächlich fügen, und dafür Sorge tragen, dass nichts doppelt auftreten kann; auch wenn es mir jetzt gerade nicht so gefällt.

Wenn aber tagelang drei Leute auf einen einreden - irgendwann wird man schwach 😉

Ich dachte, dass ich damit klar gesagt habe, dass Ihr mich überzeugt habt.

Schade, dass Du das überlesen hast und mir dann zum Abschluß noch sowas reinwürgst, obwohl ich meine Meinung geändert habe 🙁

Btw: den Artikel von Microsoft habe ich schon so verstanden, wie er gemeint war. Sollte eigentlich auch mehr ironisch rüberkommen, und zeigen, .... aber is ja auch egal jetzt. Witze erklärt man nicht 😉