..., dass ich das Menü noch nie aufgemacht hab...
Wer hat das schon?

Generell: jede Person, die sich ein bissel für ihren PC, bzw. das Betriebssystem und dessen Möglichkeiten interessiert.

Hier: jede Person, die gelegentlich den Windows-Taschenrechner benutzt.
Warum? -> Um zu sehen, welche Möglichkeiten er bietet.

@norman_timo
Dann ist Dir ja wahrscheinlich auch neu, dass man mit dem Rechner sogar Zahlensysteme umrechnen kann 😁 :evil:

Wieso sollte man mit der Version nicht kommerzielle Programme erstellen können? Mit der Express darf man das ja auch.

Naive Schlußfolgerung...

Die Frage ist nur ob noch ein Server aufzutreiben ist, von dem das Spiel gesaugt werden könnte.

Weiß nicht, ob Du das meinst, aber vielleicht passt es ja.

OLECoordinateSystem

Windows-Standard halt - seltsam, dass das für so viele Leute etwas Neues ist.

mich würde an dieser stelle interessieren wie es denn aussieht wenn ich sagen wir mal eine hirarchietife von 30 subelementen habe.

@Atomroflman
Genau das meinte ich mit

für einen XML-Editor fehlt mir hier, auch wenn das Konzept auf einem Grid basiert, die Abbildung der hierarchischen Struktur des Dokumentes.

Die Betonung liegt hier auf Struktur; nicht auf hierarchisch.

Ansonsten

Die Toolbar spricht wohl für sich:
Load = Laden einer XML
Save = Speichern der aktuellen XML
Add = hinzufügen von Tabellen, Spalten, Zeilen

Screenshots einer Toolbar sind nichtssagend. Klar kann man sehen, was ein Klick auf einen der Buttons bewirken soll; aber ob er das auch tut?!

Ich wollte mit meiner Kritik nur zeigen, dass man eine Arbeit nicht anhand von Screenshots beurteilen kann.

[...]da ja anscheinend auch kein Interesse besteht[...]

Was erwartest Du bitte, wenn Du hier irgendein Vorhaben ankündigst? Das jeder himmelhoch jauchzend 'Hier!!!' schreit? Zeige Resultate - alles andere ist Schall und Rauch!

Wenn die Regierung sagt, dass sie die Steuern senken wird, dann geht mir das auch am A vorbei, solange ich davon nichts auf meiner Abrechnung sehe.

Auch ein Screenshot hilft wenig, um sich ein Urteil über Deine Arbeit erlauben zu können.

Nur soviel (auf Basis des Screenshots): für einen XML-Editor fehlt mir hier, auch wenn das Konzept auf einem Grid basiert, die Abbildung der hierarchischen Struktur des Dokumentes.

Ich ziehe gedruckte Werke noch immer den elektronischen Ausgaben vor. Warum? Ich muss nicht zwingend vor dem Rechner sitzen, sondern kann mich entspannt aufs Sofa oder sonstwo hin legen (nein, ich habe privat kein Laptop).

Wenn es um Fachbücher geht, deren Inhalt ich direkt am PC nachvollziehen möchte, muss ich nicht permanent hin- und herswitchen (nein, ich habe keinen zweiten Monitor).

Ich kaufe mir sogar die Printausgaben von elektronisch kostenlos verfügbaren Medien, wie beispielsweise dem Visual C# openbook.

Die elektronischen Ausgaben nutze ich nur zur Volltextsuche, oder zum schnellen Nachschlagen bei der Arbeit o.ä.

Ach herrje schäm

Danke Euch!

Dumm: jetzt habe ich komplett vergessen, was ich eigentlich damit bezwecken wollte 🤔

60 Mensch Paladin (Der Rat von Dalaran)
60 Mensch Schurkin (Der Rat von Dalaran)
60 Untote Hexenmeisterin (Die Arguswacht)
59 Troll Schurkin (Die Arguswacht)
52 Nachtelf Jägerin (Die Aldor)
diverse andere

Bis auf 'Krieger' habe ich alle Klassen bis min. Stufe 40 durch; sprich alle haben ein Mount.

Als ich mir dann nach langer Zeit 'The Burning Crusade' zugelegt habe, habe ich einen Tag später aufgehört, zu spielen... daher kein 60+ Charakter.

Hallo zusammen,

stehe gerade vor einem etwas mysteriösen Problem.
Ich habe die beiden folgenden Testklassen (dienen nur der Veranschaulichung des Problems!):

	public class KlasseA
	{
		public int i = 5;
	}

	public class KlasseB
	{
		
	}

Ich möchte nun in KlasseB eine Instanz von KlasseA erzeugen, und den Wert in i abfragen oder setzen.

	public class KlasseB
	{
		KlasseA klasseA = new KlasseA();		
	}

Die Instanziierung funktioniert auch; ich kann das Projekt kompilieren.
Das Problem liegt darin, dass ich nicht auf die Instanzvariable 'klasseA' zugreifen kann.
IntelliSense bietet mir diese nicht an; und wenn ich sie einfach ohne IntelliSense hinschreibe, und auf i zugreifen möchte,

	public class KlasseB
	{
		KlasseA klasseA = new KlasseA();		
		klasseA.i = 1;
	}

dann erhalte ich die Meldung

Ungültiges Token "=" in Klasse, Struktur oder Schnittstellenmemberdeklaration.

Umbenennen der Klassen, Instanzvariable, Member etc. hat nicht geholfen; auch der Neustart der IDE nicht.

Weiß jemand Rat?

So ganz versteh ich das jetzt nicht mit dem PostScript... das sind ja nur zusatzliche befehle oder?

Ganz so einfach ist PostScript nicht 😉
Das sind nicht zusätzliche Befehle - es sind prinzipiell ausschließlich PostScript-'Befehle'.
Druck Dir mal mit einem Editor ein paar Textzeilen mittels PostScript-Treiber in eine Datei und schau Dir diese an.
Achtung: nicht vor Schreck umfallen! Vom Treiber generierte PostScript-Dateien sind schlecht bzw. gar nicht formatiert - alles wird hintereinander weggeschrieben, so dass das Ganze recht chaotisch aussieht 😉
Bei Adobe bekommst Du übrigens irgendwo die PostScript-LanguageReferenz - ein 912 Seiten starkes PDF-Dokument - viel Spass beim lesen 😉

Wie könnte man hier mit Pinvoke oder so die daten an den drucker senden?

Mit 'WritePrinter' -> schaust Du [URL="http://www.pinvoke.net/search.aspx?search=writeprinter&namespace=[All]"]hier[/url]

Edit: URL korrigiert

Hallo,

wie genau das unter C# funktioniert (mit dem Drucken) kann ich Dir leider nicht sagen, da ich noch nicht so weit bin. Die Grundlagen solltest Du aber im 🛈 finden.

Unter Delphi habe ich mal eine PostScript-Engine für unsere Software geschrieben.
Dort habe ich die Befehle dann direkt an den Druckerspooler geschickt.

Es scheint mir trotz der neu hinzugekommenen Themen allerdings nicht umfangreicher. Irgendetwas ist bestimmt zusammengestaucht worden.

Habe zu Hause die Print-Version der 2005er Ausgabe; werde mal vergleichen.

Ich persönlich finde es mindestens genau so schlimm, dass die Rechtschreibung und Textgestaltung in öffentlichen Bereichen, insbesondere Foren, immer mehr verkommt.

Ist die Tatsache, dass hier oftmals nicht Unvermögen, sondern einfach nur Faulheit schuld ist, Fluch oder Segen?

Gerade die notorischen Satzzeichenvergesser und Kleinschreiber fallen da besonders ins Gewicht.
Ich finde es gebietet der Höflichkeit, sich an manche Spielregeln zu halten, wenn man mit anderen Menschen kommuniziert; und da gehört für mich Interpunktion sowie Einhaltung der Regeln von Groß- und Kleinschreibung einfach dazu.

****
Ja los, sucht...

Ich war gerade eifrig beim lesen des OpenBook 'Visual C# 2005' , als ich beim virtuellen Umblättern plötzliche eine 'Not found' Meldung bekam.
Verwundert habe ich die Galileo-MainPage angesteuert , und siehe da: die aktuelle Auflage des Klassikers ist nun verfügbar.

Toll: das Buch hat nun eine Volltextsuche, was vorher glaube ich noch nicht der Fall war.

Visual C# 2008

Für solche Ausnahmen gibt es IETab.

Ich bin mit dem Firefox 3 bestens zufrieden, auch wenn ich von der erhöhten Geschwindigkeit nichts merke.

Alle meine AddOns funktionieren (auch TabMixPlus - hier mal die aktuelle Entwicklungsversion runterladen!), auch wenn teilweise etwas manuelle Nacharbeit (hochsetzen der max-version) notwendig war, um eine Installation möglich zu machen.

An all diejenigen, denen (wie mir) die neue Navigationsleiste nicht gefällt: es gibt ein AddOn namens Oldbar. Damit ist zumindest sichergestellt, dass bei Eingabe von 'my' auch nur die Einträge angezeigt werden, die mit 'my' beginnen. Leider gibt es bzgl. der Anzahl der angezeigten Einträge eine Limitation, was bei FF2 nicht so war - sehe ich aber als kein großes Problem an.

@Qwald
Mein Tipp: einfach mal ein bissel suchen, wenn man Probleme hat, oder einem dieses oder jenes nicht gefällt; und nicht gleich alles hinschmeißen!
Gerade bei nicht funktionierenden AddOns muss man sich mal ein bissel akribischer auf die Suche machen, und nicht glauben, dass auf Seiten wie www.erweiterungen.de etc. immer die aktuellste Version bereit steht...

Hallo,

Ich bin jetzt auch auf der Suche nach einem ähnlichen Ersatz. Vor allem die Funktion, überflüssige using-Anweisungen angezeigt zu bekommen fand ich gut.

Eigendlich müsste das VS Studio solche DInge schon implementiert haben aber da ist M$ ja wenig innovativ. Andere Entwicklungeumgebungen (Eclipse z.b.) sind da schon ein wenig weiter in der Entwicklung.

zumindest entfernen kannst Du nicht benötigte Using-Direktiven ( VS 2008 ) über das Kontext-Menü des Editors.

Hallo zusammen,

wenn sich die Toolbox mit immer mehr Controls füllt, kann das Ganze irgendwann doch recht unübersichtlich werden.

Leider habe ich weder eine 'hausgemachte' Lösung, noch ein AddIn o.ä. gefunden, welches mir eine Suche in der Toolbox ermöglicht.

Ich stelle mir das in etwa so vor, dass ich in einer Textbox den Namen eines Controls eingebe, und mir die Toolbox dann ausschließlich die Controls anzeigt, die matchen; idealerweise per Live-Suche.

Kennt da jemand etwas passendes?

Auch wenn dieser Fall nicht so gravierend ist und dieser Kommentar eher allgemein gelten soll, möchte ich Dir einen guten Rat geben.

In rechtlichen Fragen solltest Du immer mit Leuten sprechen, die sich hauptsächlich mit solchen Themen auseinandersetzen; in diesem Fall Finanzbeamte oder aber Rechtsanwälte.

Was hindert Dich daran, einfach bei der für Deinen Wohnort zuständigen Finanzverwaltung anzurufen, und nachzufragen?
Generell würde ich mir das sogar schriftlich bestätigen lassen.

Du kannst Dich sogar kostenlos an Anwaltskanzleien wenden, die Dir dafür nichteinmal die Kosten für ein Beratungsgespräch in Rechnung stellen.
Suche Dir irgendeine Kanzlei aus den Gelben Seiten, rufe dort an und schildere kurz Deine Situation.

Ohne denjenigen, die Dir bisher geantwortet haben, zu nahe treten zu wollen; verlasse Dich in rechtlichen Fragen niemals nicht auf Antworten, die Du von irgendjemandem in irgendeinem Forum bekommst.
Leider herrscht diesbezüglich zu oft zu viel Halbwissen. Als grobe Richtung kannst Du diese Antworten natürlich auf Dich wirken lassen; solltest Du aber auf die Nase fallen, so kann Dir von den Forenusern niemand helfen; auf deren Aussagen kannst Du Dich nichteinmal berufen!

Auch wenn sich das für den Einen oder Anderen etwas überzogen anhören mag; schnell kann aus Kleinigkeiten, etwas ganz Großes werden und Recht ist komplizierter als Mancheiner denkt.

[...] Ich denke [...]

[...] ich denke man kann [...]

[...] Ich denke das wäre [...]

[...] Denke solange [...]

Irgendjemand sagte einst 'Denken heißt nicht wissen'. Also beherzige diesen Ratschlag; denn jeder, der in dem Thema nicht firm ist, kann nur Vermutungen anstellen - und das kann -für Dich- böse enden.

Bevor es jetzt wieder auf mich herabprasselt: nochmal den ersten Satz lesen.

Hallo,

strukturieren kannst Du Deinen Code bspw. mit Regionerate.

Bzgl. des Aufräumens müsstest Du etwas konkreter werden.

Hallo,

ist mir vorgestern auch passiert 😉

STRG+E,S

Alternativ übers Menü

[Bearbeiten | Erweitert | Leerstellen anzeigen]

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 😉

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 😉

@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

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(

8o

Entschuldigung an JAck30lena und auch an Dich, Khalid.
Besonders aber an JAck30lena; dem habe ich es wohl nicht so leicht gemacht, mit meinem 'Ich habe aber recht, weil der Objektbrowser mir das sagt'-Gepoche - 'tschuldigung 🙁

Frei nach herbivore: "Ein Screenshot sagt mehr als 1000 Worte" X(

Naja, da hab ich wohl derbe ins Klo gegriffen. Aber woher soll ich auch wissen, dass mir das Arbeitswerkzeug, das mir für viel Geld an die Hand gegeben wird, die Hälfte verschweigt?!

Traurig 🙁

schau dir das doch im reflector an. denkst du ich versuche dich anzulügen?

In welcher Hinsicht? Damit, dass sich der Namespace 'System' nicht in 'vielen' Assemblies widerfindet, sondern nur in dreien?
Was kann mir der Reflector mehr sagen, als der IDE-interne Objektbrowser?

Nein, Du willst mich ganz bestimmt nicht anlügen; ich glaube, dass wir an diesem Punkt ganz kräftig aneinander vorbei reden.

Ich habe es gerade nochmal überprüft, und dabei ist mir aufgefallen, dass sich der Namespace 'System' in einer vierten Assembly befindet; an 'mscorlib' hätte ich nicht gedacht.

Ich habe Dir mal einen Screenshot angehängt, vielleicht wird dann klar, was ich meine.
Dort ist ganz klar ersichtlich, dass sich der Namespace 'System' in vier Assemblies befindet.

Und daran gibt es doch wohl nichts zu rütteln. Oder willst Du sagen, dass der Objektbrowser uns anlügt? 😉

(Der Reflector sagt übrigens das Gleiche.)

fogendes:
namespaces sind logische einheiten.
assemblies sind physikalische einheiten.

Das weiß ich.

du kannst z.b. pro assemblei je ein conrolsatz haben mit allem was dazugehört.

Auch damit erzählst Du mir nichts Neues.

alle controls können auch im selben namespace sein. das hat dann den vorteil, das der anwender nicht 123123123123 usings in seinem code haben muss.

Ich denke, dass ich mich dazu bereits geäußert habe. (Stichworte: Übersichtlichkeit / 10 Jahre später, u.U. redundante Typnamen usw...)

aus diesem grundsatz kannst du auch schlussfolgern, das ein namespace keinen klassennamen tragen sollte, da eine klasse keine logische gruppierung ist, sondern eine konkrete (ich nenne es mal) "bauanleitung".

Nö, eine klasse würde ich eher als logische Grundlage eines zu realisierenden physikalischen Objektes ansehen.

Aber ist auch alles egal jetzt.
Ich mache das jetzt so, wie ich am besten klarkomme und fertig.

Habe den FXCop zum Spass mal über einige Assemblies rattern lassen, die ich hier im Forum unter 'Projekte' gefunden habe.
Bei teilweise über 200 Meldungen liege ich mit meinen vier Meldungen (ja, auch 'der Klassenname soll nicht dem Namespacenamen entsprechen') ja noch recht gut im Rennen 😁

Edit:@Khalid
Genau das ist der Punkt, an dem ich denke, dass wir aneinander vorbei reden (also JAck30lena und ich)
In der System.xml.dll sehe ich keinen Namespace System, wie der untere Teil des Screenshots zeigt.

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).

Ach herrjeminechen 😠

Nun gut, dann werde ich mich bzgl. MakeFiles wohl mal schlau machen müssen.

(Nein, ich bin nicht doof. Nur erstellt bei uns in der Firma jemand anderes die Builds. Und für private Zwecke brauch(t)e ich keine MakeFiles 😉 )

Danke für den Tipp!

Und der Namespace 'System' ist in der System.dll.
das siehst du vollkomen falsch.

der namespace ist in vielen dll´s wie ich bereits schrieb und jede dll bringt ein paar klassen dazu.

So, bin jetzt den kompletten Objektbrowser durchgegangen.
Du hast recht; der Namespace befindet sich in mehr als einer DLL. Aber 'viele' sind das auch nicht; denn es sind genau drei, in denen sich der Namespace 'System' (nur 'System', nicht 'System.xml' oder 'System.irgendwas') befindet:

System.dll
System.Core.dll
System.ServiceModel.Web.dll

Damit wäre das Verfahren leider nicht praktikabel

das Verfahren, dass ich oben geschrieben habe, funktioniert anders als du es probiert hast und es funktioniert.

Hmm, Du schriebst, ich solle den gesamten Code des Namespaces in eine Assembly linken.
Da sich besagter Namespace in mehreren Assemblies befindet, muss ich doch einfach - nee, das ist quatsch.
Aber wie kann ich das denn einfach machen?
Muss ich mir dann alles, was zu einem Namespace gehört, per Copy&Paste zusammen in eine Quellcodedatei kopieren? 8o
Das kann bei x-Ursprungsquellcodedateien aber ganz schön mühselig sein.

Oder gibt es eine Vorgehensweise, die einfacher ist?

Da ich nicht alles in einen Ordner stopfe, sondern meine Projekte ordentlich strukturiert auf der Festplatte ablege, müsste ich mir dann erst aus den einzelnen Projekten die Assemblies mit dem entsprechenden Namespace heraussuchen.
gerade wenn die Projekte ordentlich strukturiert sind, solltest du da nicht lange suchen müssen.

Da hast Du recht, das müsste ich auch nicht 😉
Ich habe es gerade mal ausprobiert.

Zwei DLLs mit unterschiedlichem Namen.
Beide haben den gleichen Namensraum TestNamespace
Jeder der beiden Namensräume hat die Klasse TestKlasse
Ich binde die beiden DLLs als Verweis in ein Projekt ein und kompiliere es => funktioniert ohne Probleme.
Erst dann, wenn ich eine der beiden Klassen direkt ansprechen will, meckert der Compiler.
Damit wäre das Verfahren leider nicht praktikabel - schade 🙁

dann würde sich wohl auch jeder daran halten
Darauf würde ich nicht Wetten. Nichts ist so schwer durchzusetzen, wie Konventionen. Es gibt immer Abweichler. Das sieht man gut hier an dem Code, der im Forum gepostet wird. Um so bezeichnender ist es, dass es am Punkt "keine Klassennamen als Namespacesnamen" keine Abweichler gibt.

Nun ja, dass Namensräume nicht die Namen ihrer Klassen enthalten sollen ist ja auch eine Konvention; und diese hat sich ja unbestritten durchgesetzt 😉
Woher weißt Du denn, dass es bzgl. der Bennenung von Namensräumen keine Abweichler gibt?
Die paar Leute, die ihren Code hier im Forum posten, sind im Vergleich zur gesamten .NET-Gemeinde kaum repräsentativ 😉
Auch wenn man schon sich viele Fremdprojekte angeschaut hat - ich glaube, eine Aussage zu treffen, die auf die Mehrheit aller .NET-Entwickler zutreffen ist, ist nicht einfach.

denn ich habe keinerlei funktionelle Einschränkungen dadurch.
Nö, nur die Benutzer deiner Klassen, die sich an den nötigen Usings die Finger wund schreiben. 🙂

Stimmt 😠
Mich persönlich würde es nicht stören, da ich es aus Delphi gewohnt bin, zig Units in der Uses-Klausel unterzubringen 😉

Hallo s-sharp,

Sind meine Bedenken denn so absurd, dass sich diesbezüglich noch niemand Gedanken gemacht hat [...]?
Wenn du so fragst ... 🙂

😉

Das tut er aber nicht. Er meckert erst, wenn zwei Assemblies, die einen gleichen Namespace haben, und diese widerum einen gleichen Typen haben aufeinandertreffen.
Das ist doch nur eine Frage deines Build-Prozesses. Bevor du eine neue, einzelne Assembly auslieferst, übersetzt du den gesamten Code des entsprechenden Namespaces testweise zusammen in eine einzige Assembly. Gibt es keine Konflikte, kannst du die einzelne Assembly ausliefern. Gibt es Konflikte, benennst du die beteiligten Typnamen um, übersetzt die einzelne Assembly neu und bist fertig.

Okay, das wäre eine Möglichkeit. Allerdings eine, die mit nicht wenig Arbeit verbunden ist.
Da ich nicht alles in einen Ordner stopfe, sondern meine Projekte ordentlich strukturiert auf der Festplatte ablege, müsste ich mir dann erst aus den einzelnen Projekten die Assemblies mit dem entsprechenden Namespace heraussuchen.
Darüber muss ich mal genauer nachdenken, ob sich das praktikabel umsetzen lässt.
Von Grund auf ausschließen würde ich das jetzt nicht 🙂

Jedenfalls sind deine Bedenken kein Grund schlechte Namespace-Namen zu verwenden. Du "missbrauchst" dann die Namespaces, um eine Schwäche deines Build-Prozesses zu stopfen.

Also als 'schlecht' würde ich das nicht bezeichnen. Es entspricht, zugegebenermaßen, nicht dem Standard, dem sicherlich 98% aller .NET-Entwickler folgen. Aber es ist nicht 'schlecht', denn ich habe keinerlei funktionelle Einschränkungen dadurch.

Es ist sicherlich auch eine Philosophie. Und wenn Microsoft in den Anfängen propagiert hätte 'Leute benennt Eure Namensräume nach den Klassen, die sie beinhalten', dann würde sich wohl auch jeder daran halten 😉

Denn vom Deployment her macht es prinzipiell gar keinen Unterschied.

Dennoch werde ich mal über Deinen Vorschlag nachdenken 😉

@Khalid
Da haben wir aneinander vorbei geredet 😉
Es ging mit um das Beispiel mit TestButton1Sichtbarkeit und TestButton2Sichtbarkeit.

@herbivore

Du hast ja recht. Und wenn der Compiler meckern würde, dass dieser oder jener Typ schon in diesem oder jenem Namespace vorhanden ist, dann wäre das ja auch alles halb so wild.
Dann würde ich sofort beim Programmieren darauf aufmerksam gemacht, und könnte etwas ändern.

Das tut er aber nicht. Er meckert erst, wenn zwei Assemblies, die einen gleichen Namespace haben, und diese widerum einen gleichen Typen haben aufeinandertreffen.
Das würde ich unter Umständen gar nicht mitbekommen, sondern vielleicht erst der Endanwender, wenn er die beiden besagten Steuerelemente gleichzeitig in einer Anwendung einsetzen möchte.
Denn dann wäre es nicht möglich, auf den Typen in der zweiten Assembly zuzugreifen, da dieser durch den aus der ersten Assembly überdeckt wird.

Bei wenigen Projekten mag man ja vielleicht noch den Überblick behalten. Da weiß man noch, dass man diesen oder jenen Typen in diesem oder jenem Projekt implementiert hat.
Wenn das, was man so fabriziert aber immer mehr und mehr wird, dann glaube ich kaum, dass sich jeder noch daran erinnern kann, ob er nicht vielleicht in Steuerelement X, was er vor drei Jahren mal programmiert hat, nicht zufällig auch die Enumeration Y verwendet hat.
Denn genau dann hat man nämlich oben genanntes Problem.

Im Gegensatz dazu weiß ich schon, dass ich vor drei Jahren mal das Steuerelement X programmiert habe, und somit den Namespace MeinName.GUI.Controls.X nicht mehr benutzen darf.
Das würde sogar dadurch ersichtlich, dass ich dann zwei Assemblies mit dem gleichen Namen hätte, da Namespacename = Assemblyname.

Der Einwand von Khalid, sämtlichen Typen den Namen des 'Haupttypen' voranzustellen, kann, was die Lesbarkeit des Codes angeht, aber auch nicht das Wahre sein - auch wenn es helfen würde.

Sind meine Bedenken denn so absurd, dass sich diesbezüglich noch niemand Gedanken gemacht hat, bzw. dieses nicht kundtut?

@JAck30lena
Das ist klar; das meinte ich so aber nicht.

'System' sehe ich als einen alleinstehenden Namespace an (auch wenn es terminologistisch nicht korrekt ist; es ist aber analog zu meiner Situation).

Und der Namespace 'System' ist in der System.dll.

Der Namespace System.Xml in System.Xml.dll - so meinte ich das.

(siehe mein Beispiel mit System.Drawing.Design)

Und das ist doch beim .Net-Framework genauso. Je Namespace eine Assembly.
nein ist es nicht.

Nicht?

Namespace = System / Assembly = System.dll
Namespace = System.AddIn / Assembly = System.AddIn.dll
Namespace = System.AddIn.Contract / Assembly = System.AddIn.Contract.dll

.....

Hmm, da habe ich tatsächlich einen gefunden.

Der Namespace System.Drawing.Design; der ist einmal in_ System.Drawing.dll_ und einmal in System.Drawing.Design.dll vorhanden 🙁

Okay, Du hast recht.

****

Kann doch nicht angehen, dass man sich eine Woche damit aufhält, wie man seine Namensräume benennt. Und dann denkt man, endlich etwas gefunden zu haben, und schon ist es wieder nicht richtig - so ein Käse 🙁

Ist mir jetzt ehrlich gesagt aber auch egal. Ich ziehe das jetzt so durch, und gut is.

Ach, ist das alles doof 🙁

Ich habe ja nicht je Klasse einen Namespace.
Ein Steuerelement kann ja auch aus mehreren Klassen bestehen; die stehen dann alle in dem Namespace; oder aber in Subnamespaces.
Dann hätte diese eine Assembly halt mehrere Namespaces.

Namespace <-> Assembly ist eine 1:n Beziehung; eine Assembly kann mehrere Namespaces beinhalten. Aber ich möchte vermeiden, dass ein Namespace über mehrere Assemblies verteilt ist, um Redundanzen zu vermeiden.

Und das ist doch beim .Net-Framework genauso. Je Namespace eine Assembly.

Wenn ich ein neues Projekt erstelle, dann bekommt der Namespace ja standardmässig auch den Namen des Projektes zugewiesen.
Innerhalb dieses Projektes kann ich dann weitere Namespaces erstellen.
Die Assembly besteht dann ggf. also aus mehreren Assemblies; also wieder eine 1:n Beziehung.

Und wenn ich dann ein weiteres Projekt erstelle, dann bekommt dieses ja wieder einen anderen Namespace.

Und solange ich keine funktionalen Einschränkungen dadurch habe, kann es ja nicht so tragisch sein.

Das eigentliche Problem ist doch, dass ich bei diesen Namespace-Geschichten nicht je Projekt aufpassen muss, keine Redundanzen zu produzieren, sondern global für jede Zeile Code, die ich produziere - sofern ich allgemeine Namespaces benutze.

Verrückte Welt.

Aus irgendeinem mir nicht ersichtlichen Grund, ist es nun doch möglich, den Klassennamen in den Namespace zu integrieren, und trotzdem ohne den vollqualifizierten Namen auf die Klasse zuzugreifen, was ja gestern nicht möglich, und deshalb der Anlass zu diesem Thread war.

In Abstimmung mit den anderen Vorschlägen, heißt mein Namespace, der das Steuerelement / die Klasse TestButton1 beinhaltet, nun so:

MeinName.GUI.Controls.TestButton1

Die Assembly entsprechend dazu dann

MeinName.GUI.Controls.TestButton1.dll

Auch wenn der FXCop anmeckert, dass der Klassenname kein Teil des Namespace sein sollte, ist das aus meiner Sicht doch die angenehmste Methode, alles in separaten Projekten zu verwalten und zu veröffentlichen, und dennoch Redundanzen sicher zu vermeiden.

Sollte irgendjemand Einwände gegen dieses Vorgehen haben, die meine Arbeit zukünftig lahmlegen würde oder durch die ich große Probleme bekommen könnte, dann höre ich sie mir natrülich gerne an 😉

Dagegen spricht zum einen die Tatsache, dass ich alles, was ich mache separat in eigenen Projekten verwalten möchte.

Zum anderen spricht dagegen, dass, wenn man das Ganze kommerziell aufzieht, und die Controls (einzeln) anbieten möchte, natürlich nicht beide in einer Assembly vertrieben werden können.

Also,

meine Assembly nenne ich TestButton1. Da es sich um ein Steuerelement handelt, wird daraus dann TestButton1.dll.

Nach Deiner Beschreibung oben müsste dann der Namespace folgendermaßen heißen:
MeinName.TestButton1.Controls
<firmenname> => MeinName
<assemblyname> => TestButton1
<logische Gruppierung> => Controls

Da habe ich dann aber wieder das ursprüngliche Problem der Gleichheit von Namespace <-> Klasse, d.h. ich könnte die Klasse TestButton1 wieder ausschließlich über ihren vollqualifizierten Namen ansprechen 🙁

Tut mir leid, aber irgendwie habe ich vollkommen den Faden verloren.

Und noch eine Frage in diesem Zusammenhang:
Gibt es für mich irgendeine Möglichkeit, solche Redundanzen innerhalb der Namespaces festzustellen?
Denn erst wenn in einer anderen Anwendung, die auf meine beiden Assemblies verweist, versucht wird, auf diese Enumeration zuzugreifen meckert der Compiler, dass die Enum in zwei Assemblies vorhanden ist.

D.h. gebe ich die beiden Assemblies weiter, bekommt der User, der sie bei sich einbaut, den Fehler, der mir vorher gar nicht aufgefallen ist, da ich die beiden Steuerelemente nicht gleichzeitig in einer Anwendung benutzt habe.

assemblynamen namespace.

<firmenname>.<assembyname>.....

Tut mir leid (für mich), aber ich verstehe nicht, was Du damit meinst 🙁

@Khalid
Das wäre eine Möglichkeit.

So, nachdem ich nun die Namensräume umgestellt habe, tut sich doch noch eine Frage auf.

(das Folgende ist nur ein Beispiel!)

Angenommen ich habe ein Steuerelement TestButton1 programmiert.
Das Projekt enthält den Namespace MeinName.GUI.Controls.
Der Name meiner Assembly lautet MeinName.GUI.Controls.TestButton1
Innerhalb dieses Namespace ist meine Klasse TestButton1 deklariert.
Desweiteren ist innerhalb dieses Namespace eine Enumeration deklariert, die ich Sichtbarkeit nenne.

So, nun erstelle ich irgendwann ein zweites Steuerelement TestButton2, was mit TestButton1 nichts zu tun hat (also nicht abgeleitet werden kann).
Auch dieses Projekt enthält den Namespace MeinName.GUI.Controls, da es sich ja ebenfalls um ein Control handelt.
Der Name meiner Assembly lautet dementsprechend MeinName.GUI.Controls.TestButton2
Innerhalb dieses Namespace ist meine Klasse TestButton2 deklariert.
Desweiteren benötigt auch dieses Steuerelement innerhalb dieses Namespace eine Enumeration Sichtbarkeit. Diese Enumeration hat allerdings andere Werte, als die Enumeration Sichtbarkeit von TestButton1.

So, und nun das Problem.
Ich erzeuge eine Anwendung, die die beiden oben genannten Steuerelemente TestButton1 und TestButton2 einsetzt.
Also füge ich den Verweisen die beiden DLLs MeinName.GUI.Controls.TestButton1.dll und MeinName.GUI.Controls.TestButton2 hinzu.

Möchte ich nun auf die Enumeration Sichtbarkeit von TestButton2 zugreifen, ist dieses logischerweise nicht möglich, da der Bezeichner Sichtbarkeit zuerst im Namespace MeinName.GUI.Controls der Assembly MeinName.GUI.Controls.TestButton1.dll gefunden wird.

Im Prinzip könnte man doch nun sagen, dass dieses Problem auftritt, da die Bezeichnung des Namespace mit MeinName.GUI.Controls zu allgemein gewählt ist, oder?

Würde der Namespace für TestButton1 so heißen: MeinName.GUI.Controls.TestButton1 und der für TestButton2 dementsprechend MeinName.GUI.Controls.TestButton2, so könnte ich bequem auf die Enumerationen beider Assemblies zugreifen.

Da hätte ich dann aber wieder das Problem mit der Namensgleichheit Namespace <-> Klasse.

Ich hoffe, die Problematik gut genug erläutert zu haben.

Ich möchte Euch wirklich nicht nerven, aber ich denke, ich muss gerade so ein grundlegendes Thema verstehen, ansonsten verrenne ich mich irgendwann ganz dolle.

Ich bin ehrlich gesagt gerade ziemlich frustriert.

Wie kann ich das denn jetzt am besten lösen? 🙁

Ich meine, so ein Namespace, der wächst ja. Und in einem Jahr weiß ich vielleicht gar nicht mehr, dass ich schon in irgendeinem anderen Projekt (welches sich im gleichen Namespace befindet) schon einmal eine Enumeration mit dem gleichen Namen habe.

Bei Klassen, da denkt man ja vielleicht noch dran, aber bei Enums...

nongui.classes.strings = nicht-visuelle Klassen, die mit der Verarbeitung von String zu tun habe; z.B. eine Klasse, die in der Lage ist, einen String rückwärts wiederzugeben
nongui.classes.files = nicht-visuelle Klassen, die mit der Verarbeitung von Dateien zu tun haben
Hallo,

ich würde diese namespaces so benennen

• Text.Classes.Strings
• IO.Classes.Files

Das war es wahrscheinlich auch, was herbivore meinte mit 'NonGui' sei ihm zu oberflächlich 😉

Danke 👍

Guten Morgen,

meinname.nongui.classes.math
umbenennen in
meinname.gui.classes.math

Klingt logisch 😉

"Classes" finde ich etwas zu allgemein für einen Namespace-Namen. Classes ist nur ein Container für einen weiteren Namespace, d.h. es wird keine Klasse geben, die direkt im Namespace Classes stehen wird; es wird immer noch einen weiteren, klassenspezifischen Subnamespace geben, wie bspw. hier math.

Ich dachte, ich könnte so eine ganz nette Abgrenzung finden.*gui.controls.math = Steuerelemente aus dem mathematischen Bereich; z.B. eine Matrix *gui.controls.graphics = Steuerelemente aus dem grafischen Bereich; z.B. eine spezielle PaintBox

*gui.applications.math = Anwendungen aus dem mathematischen Bereich; z.B. ein Formelrechner *gui.applications.graphics = Steuerelemente aus dem grafischen Bereich; z.B. ein Zeichenprogramm

*gui.classes.math = Klassen, die mathematische Funktionen zur Verfügung stellen; z.B. eine Klasse, die in der Lage ist, einen Bruch auf irgendein Control zu zeichnen *gui.classes.graphics = Klassen, die grafische Funktionen zur Verfügung stellen; z.B. eine Klasse, die in der Lage ist, einen Gradienten auf irgendein Control zu zeichnen

*gui.addons.vs = AddOns für das Visual Studio *gui.addons.office.outlook = AddOns für Outlook *gui.addons.office.word = AddOns für Word

*nongui.classes.strings = nicht-visuelle Klassen, die mit der Verarbeitung von String zu tun habe; z.B. eine Klasse, die in der Lage ist, einen String rückwärts wiederzugeben *nongui.classes.files = nicht-visuelle Klassen, die mit der Verarbeitung von Dateien zu tun haben

... etc.

Damit hatte ich mich eigentlich schon angefreundet; bin natürlich für weitere Vorschläge offen.

(Ich denke, einen perfekten Weg gibt es sowieso nicht, und den für sich selber am besten geeigneten Weg findet man im Laufe der Zeit von alleine. Nur möchte ich nicht irgendwann dastehen, und merken, dass ich mich bzgl. der Namespaces vollkommen verrannt habe; denn so einfach lässt sich ein solch essentielles Problem dann ja nicht wieder korrigieren. Deswegen möchte ich soviel von Eurer Erfahrung aufnehmen, wie eben möglich - danke!)

Okay, danke für den ergänzenden Hinweis 🙂

Habe es mit den Namensräumen nun, dank der oben genannten Beispiele, so gelöst:

für visuelle Controls:
meinname.gui.controls

für nicht visuelle Klassen (hier z.b. eine Klasse, die einen Bruch zeichnen kann)
meinname.nongui.classes.math

für Anwendungen (da ich daraus ggf. auch mal ein Steuerelement, AddOn o.ä machen könnte, ein separater Namespace für Anwendungen):
meinname.application.anwendungsname

Diese Namespaces werden auf der Festplatte dann in einer Verzeichnisstruktur abgebildet in denen sich dann alle *.cs-Dateien befinden; für jede Klasse eine.

Danke für Eure Beispiele! Das bringt mich schon um einiges weiter!

Und danke für den Smiley 😉

ein Namespaces pro Klasse führt schnell zu einer Inflation und sollte die Ausnahme bleiben.

Ich habe ja nicht gesagt, das ich einen Namespace je Klasse habe.

Wenn ich aber ein Steuerelement entwickle, dann ist der Name des Steuerelementes halt der Klassenname. Und da es das Basisobjekt ist, möchte ich, dass so (oder so ähnlich) auch der Namespace heißt.

Natürlich habe ich dann noch mehrere Klassen und Enums in diesem Namespace.

Wie würdet Ihr denn Euren Namespace und die Klasse benennen, wenn Ihr ein Steuerelement von 'Button' ableitet?

Hallo Ihr drei,

Es liegt aber nicht an der Sprache, das Du viele verschiedene Controls einbindest.

Das habe ich auch nicht behauptet. Ich sagte lediglich, dass unter Delphi standardmäßig alles in die Exe gelinkt wird. Natürlich kann ich auch da alles mögliche in DLLs auslagern; bei kleinen Tools ist das allerdings etwas oversized.

Für kleine Applikationen tuns meist auch die Controls, die im Framework dabei sind.

Das kann man so pauschal, auch bzgl. kleiner Applikationen, wohl nicht sagen.

@JAck30lena
Ich verstehe Dich schon, und kann Deine Grundaussage auch ohne weiteres auf komplexere Applikationen übertragen.
Bei "ich schreibe mir mal just ein Tool für dieses oder jenes" und muß dann externe DLLs mitgeben, weil ich eben nicht mit den Basiselementen des Frameworks ausgekommen bin, finde ich das allerdings nicht so schön.
Und die einzelnen Assemblies wirklich als Ressource einbinden, dann zur Laufzeit wieder auspacken etc., das kanns ja auch nicht sein 😉

Das Projekt an dem ich sitze, hat allein in seinem Releaseordner ca. 50 DLLs liegen (Eigene und Fremde). Warum so viel hat mehrere Gründe. Unter anderem, weil es halt vorkommen kann, das für bestimmte Kunden bestimmte Anforderungen gelten. So müssen nur 1-2 DLLs getauscht werden und gut ist. Alles andere bleibt wie es ist.

Auch das kann ich ohne Probleme nachvollziehen.
Unser Hauptprodukt sieht ja auch nicht anders aus.
Mir geht es aber um kleine Tools, die man gerade mal so schreibt.

Leg Delphi weg und denk nicht mehr dran

Kann ich leider nicht, da ich das beruflich benötige.

Ich habe die Tools, die ich bisher geschrieben habe, als einfache Exe weitergegeben; ohne irgendwelche externen Bibliotheken oder Installationsroutinen und sonstwas.

Runterladen, starten und bei Bedarf wieder löschen - fertig.

Siech diesbezüglich umzustellen ist leichter gesagt, als getan. Aber ich werde mich bemühen 😉

@talla
Na dann versuche ich mal, mich daran zu gewöhnen 😉
Einen wirklichen Vorteil sehe ich darin allerdings noch immer nicht.

1. ich weiß nicht was dich daran stört. vor allem in hinblich auf patchen und bugfixing ist das eher ein vorteil als ein nachteil

Was mich daran stört, kann ich Dir sagen.
Ich bin es nicht gewohnt, bei kleinen Tools 50 Dlls mitzuliefern, nur weil ich in dieser Anwendung 50 Steuerelemente verschiedener Anbieter nutze.

2. du kannst dll´s auch als embedded ressourcen einlagern. wie das geht, findest du in der forumssuche.

Das hört sich doch schon besser an.

Danke.

Edit:

@herbivore:

Was muss der Anwender machen, wenn er seine Anwendung, die ja mein Steuerelement enthält, weitergeben will.
Muss er dann meine DLL mitgeben?
ich denke, die Frage kannst du dir selbst beantworten, oder? Die Antwort ist doch offensichtlich.

Ja, natürlich kann ich mir die Frage selber beantworten.

Vielleicht ist es von mir ein bissel zu viel verlangt, anzunehmen, dass jemand versteht, was ich meine, wenn ich es nicht wort wörtlich beschreibe.

Edit2:

2. du kannst dll´s auch als embedded ressourcen einlagern. wie das geht, findest du in der forumssuche.

das war doch nicht das, was ich wollte.
In Delphi habe ich eine Exe-Datei weitergeben; egal, wieviele 'Steuerelemente' ich in der Anwendung hatte.
So ist doch die Gefahr viel größer, dass der User eine Dll löscht, und der ganze Klumpatsch nicht mehr funktioniert.... 🙄

....
Ich glaube, ich habe die falsche Sprache gewählt.
Dass jeder meinen Code mittels Reflection auseinandernehmen kann gefällt mir nicht, dass ich zig DLLs weitergeben muss gefällt mir noch weniger...

Alles blöd.

Okay,

und was ist, wenn ich nicht den Weg über den GAC gehe?

Dann erhält der Nutzer beim Linken seiner Anwendung eine Kopie meiner DLL in seinem Ausgabeverzeichnis.
Ist im Prinzip doch das Gleiche, oder?

Setze ich 20 Steuerelemente von Drittanbietern ein, die in 20 verschiedenen Assemblys liegen, dann muss ich die alle mit weitergeben, oder?

Oder kann ich die irgendwie direkt in meine Assembly einlinken?

Ich meine, das kann doch irgendwie nicht sein, dass ich dann 50 Dateien oder so weitergeben muss, oder?