Gibt es einen "DefaultNamespace" für Klassen?

[Luckie]

Ich habe mit dem VS eine neue Klasse erstellt. Diese wird automatisch zum Projekt hinzugefügt und erhält den Namespace des Projektes. Gibt es jetzt einen standard Namespace, damit ich die Klasse auch in anderen Projekten einfach benutzen kann, ohne jedes mal den Namespace anpassen zu müssen?

[MagicAndre1981]

Was willst du jetzt?

Du kannst doch den Namespace ändern, wie du willst und dann kannst du in einem anderen Projekt die Klassen dieses Namespaces wieder nutzen

Code:

using MeinNamespace;

[Elvis]

Hmm?
DeineLib1.Klasse1 ist in DeineLib1 kompostiert, right?

Wo immer du sie benutzt reicht es doch diesen namespace in die usings einzutragen oder den vollen Pfad einzugeben.
Du kannst auch namespaces über mehrere Libraries verwenden, falls dich das innerhalb einer Solution stört.

Falls ich dich falsch verstanden habe und du die _Datei_ tatsächlich in mehrere Projekte kompilierst anstatt die gleiche Lib zu referenzieren... *iehk*
Das ist ziemlich böse und geht ganz schnell nach hinten los. Dadurch sind diese binaries komplett inkompatibel zueinander, da sie jeweils Klasse1 enthalten, aber diese ist in jedem Binary für die CLR eine andere Klasse darstellt. -> *kaboom*

[Luckie]

Mist, war ein Kurzschluss von mir. Stimmt hast ja recht.

Code:

using System;
using System.Timers;
using System.Runtime.InteropServices;

namespace SystemIdleNamespace 
{
    class SystemIdle
    {
        private System.Timers.Timer timer;
        private System.Timers.Timer timer2;
        private Int32 idleTime;
        private Int32 elapsedTime;
    ...
    ...

Und im Projekt dann:

Code:

using SystemIdleNamespace;

[MathiasSimmack]

Zitat von Elvis:

Das ist ziemlich böse und geht ganz schnell nach hinten los. Dadurch sind diese binaries komplett inkompatibel zueinander, da sie jeweils Klasse1 enthalten, aber diese ist in jedem Binary für die CLR eine andere Klasse darstellt. -> *kaboom*

Also, mit anderen Worten: Auch aus solchen Miniklassen separate Assemblies erstellen und die dann in das Projekt einbinden?

[Elvis]

Zitat von MathiasSimmack:

Zitat von Elvis:

Das ist ziemlich böse und geht ganz schnell nach hinten los. Dadurch sind diese binaries komplett inkompatibel zueinander, da sie jeweils Klasse1 enthalten, aber diese ist in jedem Binary für die CLR eine andere Klasse darstellt. -> *kaboom*

Also, mit anderen Worten: Auch aus solchen Miniklassen separate Assemblies erstellen und die dann in das Projekt einbinden?

Da du hier in der Merhzahl sprichst, könnte man glatt annehmen, du hättest mehrere davon, die du jeweils in eine gemeinsame Assembly werfen könntest?
Es gibt immer noch IlMerge wenn man ganz zum Schluss doch nur ein Binary haben will. Der Weg hat aber den Vorteil, dass du einfach das Merging aus dem Buildvorgang entfernen kannst, falls du mit einem anderen Projekt über eine gemeinsame Lib reden willst...

Es kommt nicht von ungefähr dass es so ein Krampf ist, lose, externe Code-Dateien in ein Projekt zu verknüpfen, weder MS noch #d wollen das begünstigen.

[MathiasSimmack]

Nein, ich habe nicht mehrere Miniklassen. Mir ging es nur um deine Meinung dazu. Ich persönlich sehe den Vorteil dabei. Wenn man eine häufig benutzte Klasse in eine Assembly auslagert, kann man sie in der Tat häufig benutzen (in verschiedenen Anwendungen), und man könnte sie auch aktualisieren/bugfixen, ohne dabei gleich die komplette Anwendung neu ausliefern zu müssen.
Andererseits füllt sich dann das Programm- oder der "Gemeinsam genutzte Assemblies von Simmi"-Ordner () langsam aber sicher mit Dateien im KB-Bereich. Wenn, dann sollte man es nämlich auch richtig machen und nicht Klassen für völlig verschiedene Aufgaben in eine Assembly packen.