Eigene Library

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von Niko Ortner.

    Eigene Library

    Guten Tag!

    Habe eine kleine (und evtl. blöde) Frage bezüglich eigene Libraries in VB.Net und zwar wenn ich eine DLL erstelle, kann ich nacher die Namespaces XXXX.My und XXXX.My.Resources sehen (Assembly Explorer), welche leer sind.

    Ich verstehe immer noch nicht ganz wofür diese Namespaces da sind. Falls ich z.B keine Resources in der Biblio benutze, brauche ich dann noch My.Resources?

    Danke im voraus :)

    Grüße
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „rgomez“ ()

    Da hab ich mir noch nie gedanken drüber gemacht bei meinen .dlls

    Ich würde mir das jetzt so erklären das My.Resources leer der dll einfach sagt das es keine Resources gibt.

    Meine Frage zurück wäre eher was hast du denn mit My.Resources machen? Nimmt die leere Eigenschaft denn überhaput Platz weg?
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."

    rgomez schrieb:

    wofür diese Namespaces da sind
    Namespaces ermöglichen es Programmierern, Prozeduren alle Namen geben zu können, ohne darauf achten zu müssen, dass eine Prozedur dieses Namens und dieser Signatur bereits vorhanden ist, solange sie sich in einem anderen Namespace befindet.
    Wenn Du beide Namespaces importierst, bekommst Du einen Compilerfehler, weil nicht klar ist, welcher Namespace gemeint ist.
    Namespaces dienen der Ordnung in einem Projekt in C#, leider nicht in VB.
    Wenn Du in Deinem Projekt ein Unterverzeichnis erstellst, wird eine dann in diesem Verzeichnis erstellte Klasse in C# in diesen Unter-Namespace erzeugt.
    In VB gilt für das ganze Projekt per Default ein Namespace.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Wofür die Namespaces da sind ist mir klar. Nur warum "erstellt" VS beim DLL die Namespaces My. und My.Resources wenn die leer sind? Wenn ich mir andere Libraries, von .NET Framework als auch 3rd-party ich sehe diese NS nirgendswo....
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    RodFromGermany schrieb:

    Namespaces dienen der Ordnung in einem Projekt in C#, leider nicht in VB.

    Ich bitte um Erklärung.
    Default-Namespace kann in VB deaktiviert werden, indem man die entsprechende TextBox in den Projekteinstellungen leer lässt. Da es aber in 99.9% der Fälle sowieso einen gemeinsamen Root-Namespace gibt, finde ich das besser als in C#, wo man in jeder Datei erstmal einen Namespace außen rum hat.

    @rgomez
    Namespaces "existieren" eigentlich nicht in diesem Sinne. Jeder Typ in einer Assembly hat einen Namen (z.B. Form1) und ein Namespace (z.B. WindowsApplication1, Namespaces können auch Punkte beinhalten), und jeder Typ hat eine Sichtbarkeit. Public bedeutet, dass der Typ außerhalb der Assembly auch sichtbar ist, Friend bedeutet, dass er nur innerhalb sichtbar ist.
    Die Typen in den My-Namespaces sind (standardmäßig) alle als Friend gekennzeichnet (bei manchen kann man das wohl ändern). Dekompiliert man ein Programm, sieht man die Typen auch:

    Beachte: Die Typen mit schwarzer Schrift sind als Public gekennzeichnet, die mit grauer Schrift als Friend.
    Erstellt man ein zweites Projekt und setzt einen Verweis auf das erste, kann man auch nur auf die Typen zugreifen, die Public sind:

    ("Global" ist hier nur ein Pseudo-Namespace, das alle Root-Namespaces beinhaltet.) Der Object Browser bestätigt das:


    Da Du "Assembly-Explorer" geschrieben hast: Davon habe ich noch nicht gehört. Was genau ist das und wo finde ich das?
    Es könnte ein Bug sein, bei dem alle Namespaces aller Typen zusammengruppiert und angezeigt werden, aber nur die Typen angezeigt werden, die tatsächlich Public sind.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Niko Ortner schrieb:

    RodFromGermany schrieb:

    Namespaces dienen der Ordnung in einem Projekt in C#, leider nicht in VB.
    Ich bitte um Erklärung.
    Das kann man nicht erklären, nämlich weil die Aussage ist vollkommen falsch.
    Namespaces haben in vb natürlich dieselbe Aufgabe wie in c#.

    Nur das VisualStudio arbeitet in vb und c# etwas anners damit.
    In c# gibts leider keine projektweiten GeneralImporte.
    Ausserdem keinen RootNamespace.
    Ausserdem generiert VS in c# in jede Datei einen Namespace hinein, und orientiert sich dabei anne OrdnerStruktur des Dateisystems des Pojekts.



    rgomez schrieb:

    wenn ich eine DLL erstelle, kann ich nacher die Namespaces XXXX.My und XXXX.My.Resources sehen
    Bei mir tut er das nur in WinForms-Projekten. In Klassenbibliothek-Projekten tut er das nicht.
    Habich bislang jdfs. nicht gefunden - überprüf das aber vlt. mal mit deim Assembly-Explorer was immer das sein mag.



    rgomez schrieb:

    Ich verstehe immer noch nicht ganz wofür diese Namespaces da sind.
    Das Namespace-System ist eine thematische Ordnungsstruktur.
    Also du ordnest code physikalisch, indem du ihn in bestimmte Dateien schreibst.
    Du ordnest ihn objektorientiert, indem du bestimmte Klassen anlegst.
    Und du ordnest ihn thematisch, indem du mittels des Namespace-Schlüsselwortes bestimmst, zu welchem Thema.UnterThema eine Klasse gehören soll.



    Ups - vlt. meinst du mit "diese Namespaces" ja den My-Kram.
    Jo, weiß ich auch nicht. Wie gesagt - ich glaub das ist nur sone vb-Schrulle, und nur in WinForm-ProjektTypen.
    VB generiert da auch bisserl Code hinein, den der Programmierer nicht gleich sehen soll - aber ich glaub, theoretisch und prinzipiell müsste es auch ohne gehen (geht in c# ja auch ohne).

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Niko Ortner schrieb:

    Ich bitte um Erklärung.

    ErfinderDesRades schrieb:

    Namespaces haben in vb natürlich dieselbe Aufgabe wie in c#.
    Klar.
    Nur hat Bill die Studios C# und VB leider mit unterschiedlichen Eigenschaften bezüglich der Namespaces ausgestattet, dass die Namespaces in C# eben voll und in VB eben nicht zur Geltung kommen.
    Macht in C# und in VB in einem Projekt eine tief geschachtelte Verzeichnisstruktur und legt im 3. Unterverzeichnis in beiden eine Klasse an.
    In C# steht dann in der Datei
    namespace main.folder1.folder2.folder3,
    in vb sucht man die Buchstabenfolge namespace vergeblich.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @Niko Ortner Der Assembly Explorer ist u.a. ein Teil von ReSharper. Ermöglicht im Wesentlichen beim Debugging durch die Assemblies die geladen und referenziert werden zu schauen. Sieht dann so aus das ganze:



    Grüße
    Vainamo

    RodFromGermany schrieb:

    in vb sucht man die Buchstabenfolge namespace vergeblich.

    Ja - das sagte ich ja bereits:

    ErfinderDesRades schrieb:

    Ausserdem generiert VS in c# in jede Datei einen Namespace hinein, und orientiert sich dabei anne OrdnerStruktur des Dateisystems des Pojekts.


    'RodFromGermany schrieb:

    in vb sucht man die Buchstabenfolge namespace vergeblich.
    Dann schreib sie hin, und zwar wie und wo es erforderlich ist.
    Dass vb da im Gegensatz zu c# keine Vorgabe hingeneriert, tut mir nicht weh, weil meist muss ich die c#-Vorgabe eh anpassen und nachbessern.

    Wieder einmal erweist sich c# für Anfänger sowohl schwieriger als auch gleichzeitig lehrreicher (und damit besser): In c# ist man von vornherein mit dem Konzept Namespace konfrontiert, während in vb Progger jahrelang herumproggen können, ohne auch nur einen Schimmer davon abzukriegen.

    ErfinderDesRades schrieb:

    ohne auch nur einen Schimmer davon abzukriegen
    Jou, das ist leider die Politik von Bill.
    Die Konsequenz wäre dann tatsächlich, in C# zu programmieren. :thumbsup:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Jou, das ist leider die Politik von Bill.

    @RodFromGermany Ich meine Mads Torgersen ist für .NET zuständig ;) .

    Ansonsten, was die .NET Politik betrifft: blogs.msdn.microsoft.com/dotne…he-net-language-strategy/

    Grüße
    Vainamo
    @ThuCommix
    Ja.
    (Ich beantworte Entscheidungsfragen gerne mit "ja")
    Es ist ein Insider.

    @Vainamo
    Ah, deswegen habe ich es nicht gefunden. Da kann ich jetzt nichts zu sagen, aber eventuell könnte man das an die Macher von ReSharper weiterleiten.

    @RodFromGermany
    Macht in C# und in VB in einem Projekt eine tief geschachtelte Verzeichnisstruktur und legt im 3. Unterverzeichnis in beiden eine Klasse an.

    Ich brauche eigene Namespaces (also nicht nur einen gemeinsamen Root-Namespace, in dem alles drin ist) tatsächlich nur selten. Und wenn, dann möchte ich mich nicht unbedingt an die Ordnerstruktur halten. (Ich mag es auch gar nicht, dass man in Java dazu gezwungen wird, die Packages der Ordnerstruktur anzugleichen.)

    Ich dachte erst, das wäre nur vom Template abhängig, denn in den Templates, die bei Visual Studio steht drin:
    Bei C#:

    C#-Quellcode

    1. using System;
    2. using System.Collections.Generic;
    3. $if$ ($targetframeworkversion$ >= 3.5)using System.Linq;
    4. $endif$using System.Text;
    5. namespace $rootnamespace$
    6. {
    7. class $safeitemrootname$
    8. {
    9. }
    10. }

    und bei VB einfach nur:

    VB.NET-Quellcode

    1. Public Class $safeitemname$
    2. End Class

    Ich hätte jetzt erwartet, dass VB das selbe macht wie C#, wenn man den entsprechenden Code einfach übernimmt, aber es wird tatsächlich nur der Root-Namespace generiert, der in den Projekteinstellungen gesetzt ist. Das ist schade, denn ich kann mir gut vorstellen, dass man das manchmal verwenden möchte. Aber andererseits muss ich auch sagen: "rootnamespace" ist für C# nicht gerade korrekt, weil es nicht der Root-Namespace ist.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils