Imports vs. Verweise

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

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Imports vs. Verweise

    Hi,

    beim Bereinigen meiner Programme bin ich auf eine Frage gestoßen, die ihr mir vermutlich aus dem Handgelenk beantworten könnt:

    Was ist den eigentlich der Unterschied zwischen:

    VB.NET-Quellcode

    1. Imports some.fancy.Namespace


    und dem Aktivieren des "some.fancy.Namespace" im Dialog "Verweise"

    So wie ich das sehe, habe ich in beiden Fällen das gleiche Ergebnis ... der Namespace ist in meiner Form bekannt und wird aufgelöst.

    Ist das einfach so, dass der "Imports" nur auf die Form bezogen ist und der der Verweis im ganzen Projekt wirkt ?

    Ich hoffe, meine Frage ist nicht gar zu blöde ... ich bitte um Nachsicht, wenn ich wieder mal meine grenzenlose Unkenntnis unter Beweis gestellt haben sollte. :)

    LG
    Peter
    Es gibt kein "Imports" vs "Verweise", denn ohne Verweise auf etwas gibt es nämlich keine Imports für etwas und kann daher auch nicht angesprochen werden. Du kannst die Namespaces einer dll erst dann "Importieren" wenn sie in den Verweisen bekannt gemacht wurde.

    Imports sind dazu da dir Tipparbeit zu ersparen, da du ja sonst immer die Namespaces ausschreiben müsstest.
    Ein Verweis benötigst du, um eine DLL überhaupt in dein Projekt einzubinden und verwenden zu können.
    Das Imports is im Grunde nur eine Art verkürzte Schreibweise und eigentlich "unnötig". Zudem kann es als Alias verwendet werden.
    Es ermöglicht dir nur zB

    VB.NET-Quellcode

    1. dim fi as FileInfo


    zu schreiben anstatt von

    VB.NET-Quellcode

    1. dim fi as System.IO.FileInfo.

    Oder wenn du deinen Import einen Alias gibst(was ggf. sinnvoll ist, bei Namespacekollisionen)

    VB.NET-Quellcode

    1. Imports IO = System.IO


    Dann schreibst

    VB.NET-Quellcode

    1. dim fi as IO.FileInfo


    Ohne einen Verweis auf die DLL in deinem Projekt, kannst du auch nix aus einer DLL importieren. Durch Import hast direkte Verweise auf Typen, die in dem Namespace enthalten sind.(Gilt für diese Codedatei)
    Das ist meine Signatur und sie wird wunderbar sein!
    Der Verweis ist zwingend erforderlich.

    Peter329 schrieb:

    Imports
    verkürzt im Quellcode den Zugriff auf die Namespaces.
    Und Du kannst beim Importieren noch Aliase generieren:

    damit kannst Du Dir z.B. den Zugriff auf fern deklarierte Enums drastisch vereinfachen.
    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!
    Also, erst mal herzlichen Dank für die Antworten.

    Aber offen gestanden verstehe ich immer noch Bahnhof.

    Nehmen wir mal an, wir haben (teuflischerweise) den Verweis "Microsoft.VisualBasic" aktiviert.

    Dann geht die Definition:

    VB.NET-Quellcode

    1. Dim myCrLf As String = vbCrLF


    ohne Probleme durch.


    Jetzt deaktiviere ich den Verweis "Microsoft.VisualBasic" . Postwendend wird die Definition erwartungsgemäß moniert:

    "vbCrLF" wurde nicht deklariert. Auf das Objekt kann aufgrund seiner Schutzstufe möglicherweise nicht zugegriffen werden.

    Und nun füge ich den folgenden Import hinzu:

    VB.NET-Quellcode

    1. Imports Microsoft.VisualBasic


    Und schon klappt die Sache wieder !

    Kann mir das jetzt jemand erklären ?

    LG
    Peter

    Peter329 schrieb:

    erklären
    Der Haken steht bei "Importierte Namespaces", nicht aber bei "Verweise".
    Wenn Du Dir den Namespace hintenrum wieder reinholst, funktioniert das natürlich.
    Wie es aussieht, ist VisualBasic keine separate DLL, die man abwählen kann.
    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!
    In C# funktioniert das nicht. Es gibt den Namespace Microsoft.VisualBasic aber in mehreren DLL's.
    Nicht nur in der Microsoft.VisualBasic.DLL. Daher vermute ich, dass bei VB Projekten einige Sachen auch noch in anderen Core Bibliotheken drin sind. Bei mir ist nach Entfernen der Ms.VisualBasic DLL nur noch Microsoft.VisualBasic.VBCodeProvider verfügbar. (Aus der System.dll).
    Das ist meine Signatur und sie wird wunderbar sein!
    Ok ... der Dialog heißt "Importierte Namespaces" ... hat das jetzt gar nichts mit Verweisen zu tun ?

    Und welche .dll Dateien werden wo angezogen ... also jedenfalls unter VIsualBasic finde ich kein .dll Dateien ... allenfalls unter vb*.dll finden sich bei mir 70 müde Dateien mit mehr oder weniger kryptischen Namen ...

    Was passiert denn jetzt, wenn ich "Imports Microsoft.VisualBasic" kodiere ? Und was passiert, wenn ich im Dialog Verweise einen Namespace importiere ?

    LG
    Peter

    Peter329 schrieb:

    Und was passiert, wenn ich im Dialog Verweise einen Namespace importiere ?
    Die im Dialog Verweise importierbaren Namespaces sind als Import vorhanden, ohne dass explizit da ein Imports System oder so im Quelltext steht.
    Diese beiden Herangehensweisen sind äquivalent:
    Entweder System.IO per Importierte Namespaces einfügen, dann ist dieser Namespace in allen Quelldateien dieses Projekts verfügbar
    oder
    Imports System.IO in die Quelldatei schreiben, dann ist dieser Namespace nur in dieser Datei verfügbar.
    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!
    Zunächstmal: Microsoft.VisualBasic ist in vb ein Zwangsverweis, den man nicht entfernen kann (im gegensatz etwa zu System.Drawing, System.Xml etc). (Er wird im Verweise-Dialog nichtmal angezeigt, aber zB. im ObjectBrowser.)

    wenn du Imports Microsoft.VisualBasic an den Anfang einer Datei schreibst, hast du diesen Namespace innerhalb der Datei importiert. Das heißt, alle Namen innerhalb des Namespaces sind "sichtbar".
    Wo man ohne Import schreiben muss

    VB.NET-Quellcode

    1. dim s = Microsoft.Visualbasic.InputBox("hi", "hahu")
    kann man bei gesetztem Import kurz schreiben:

    VB.NET-Quellcode

    1. dim s = InputBox("hi", "hahu")
    Denn der Name InputBox ist durch den Import sichtbar gemacht worden.
    Und selbiges gilt für den gesamten anderen Schrott, der im Microsoft.Visualbasic-Namespace enthalten ist (Split, Mid, Msgbox, Len, Left, FileOpen,...) lauter lauter Müll.
    Und Intellisense spielt dir diesen Müll ständig unter die Tastatur.

    Und der Dialog heißt "Importierte Namespaces" - er heisst nicht "Verweise".
    Und er bedeutet dasselbe wie wenn du die Imports-Anweisung an den Anfang einer Datei schreibst. Nur ist es ein General-Import, also das gilt für alle Dateien des Projektes.



    So, nun Verweise.

    Verweise verweisen auf Dlls, wo vorkompilierter Code drin ist. Sie können auch auf Projekte verweisen, die du grad inne Solution offen hast. Ist das gleiche, heisst glaub "Assembly".
    Also eine Assembly stellt Code bereit, den du benutzen kannst. Dein Projekt muss dazu auf die Assembly verweisen.

    Innerhalb der Assembly ist der Code in Namespaces gegliedert. Also eine Assembly enthält Code in mehreren Namespaces.
    Oft ist sogar in verschiedenen Assemblies Code drin für den gleichen Namespace.
    Beim ObjectBrowser kann man sich auch eine Ansicht einstellen, die die Assemblies als Root-Elemente zeigt. Und da kann man dann aufklappen, und gugge, welchen (mehrere) Namespaces eine Assi ihren Code zuordnet.

    Ja, und jetzt wissemer ja, was Importieren ist, und was es bewirkt.
    Nochmal Beispiel - ein FileInfo erstellen, entweder so

    VB.NET-Quellcode

    1. Dim fi As New System.IO.FileInfo("C:\Mamamia\Blabla.txt")
    (vollqualifiziert)

    Oder so

    VB.NET-Quellcode

    1. Imports System.IO
    2. '...
    3. Dim fi As New FileInfo("C:\Mamamia\Blabla.txt")

    Oder so

    VB.NET-Quellcode

    1. Dim fi As New FileInfo("C:\Mamamia\Blabla.txt")
    wenn der GeneralImport auf System.IO gesetzt ist (nicht empfohlen).



    Generell gilt: Importe ermöglichen Kurzschreibweisen, wo man sonst vollqualifizierte Namen angeben müsste.
    Importiert man aber zuviel, so wird die Intellisense "dummschwätzig", und in seltenen Fällen treten sogar Namenskonflikte auf.

    Also eher sparsam importieren, das focussiert auch die Code-Datei gewissermassen auf ein Thema.

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

    Ich war mit ein paar Dingen aus meinem realen Leben beschäftigt. Aber jetzt wende ich mich wieder den wirklich wichtigen Dingen zu, dem .NET Framework. :)

    Danke erst mal für eure zahlreichen Beiträge. Soviel Zeit muss wie immer sein.

    Ich hab das alles aufmerksam gelesen. Trotzdem hab ich mehr Fragen als vorher. Zunächst mal, was ich verstanden haben:

    Verweise sind Einträge (?), die auf .exe und .dll Objekte verweisen. In diesen Objekten sind Klassen enthalten ... und durch den Verweis werden diese Klassen, sowie deren Eigenschaften und Methoden addressierbar. Ist das so richtig ?

    Fragen eines denkenden Lesers dazu:

    1. Wie erstellt man denn so einen Verweis ? Also ich meine nicht, wie man den durch Setzen eines Häkchens aktiviert. Sondern wie man so ein Dingens EINRICHTET.

    2. Verweise sind ja irgendwie hierarchisch organisiert. Microsoft.VisualBasic ... Microsoft.VisualBasic.Constants ... etc. ... Was heißt das denn nun für die Verwendung? Wenn ich Microsoft.VisualBasic aktiviere, sind dann auch automatisch alle darunter liegenden Einträge aktiviert? Also z.B. Microsoft.VisualBasic.Constants ?

    Die Inhalte eines solchen Verweises kann man sich wohl im ObjectExplorer ansehen (der dann im VB Studio als ObjectCatalog referenziert wird, damit die Sache nicht ganz so klar ist, wie sie sein könnte :) )

    Unter MicroSoft.VisualBasic[10,0,0,0] findet man dann

    Assembly Microsoft.VisualBasic Member von .NET Framework 4 C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Microsoft.VisualBasic.dll

    Das ist doch dann wohl die Datei auf die verwiesen wird. Wenn ich die jetzt mit dem "DependencyWalker" öffne ... dann erhalte ich ein ziemlich kryptisches Ergebnis ... außer ein paar verwirrenden Fehlermeldungen sehe ich nix, was irgendwie auf Funktionen wie "MsgBox" hinweist.

    Im Object Explorer finde ich dann auch nur ein Display, das mir mehr Fragen als Antworten liefert.

    Unter VisualBasic finde ich jedenfalls auch nix was auf die vermaledeite "MsgBox" hinweist.

    Na, ich hab mal die Displays angehängt ... vielleicht hat ja jemand Geduld mir das näher zu bringen.

    LG
    Peter
    Bilder
    • Dependency Walker.jpg

      591,24 kB, 1.440×760, 168 mal angesehen
    • ObjectExplorer.jpg

      836,86 kB, 1.531×1.034, 185 mal angesehen

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

    Peter329 schrieb:

    Verweise sind Einträge
    Letztenendes sind Verweise eine Liste von DLLs, die geladen werden.

    Peter329 schrieb:

    alle darunter liegenden Einträge
    sind nach meinem Verständnis separate DLLs, auch wenn sie im selben Namespace liegen, sonst würden sie nicht in dieser Liste auftauchen.
    Der Dependency Walker macht bei .NET-Assemblies meiner Meinung nach einigen Mist.
    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!
    Danke erst mal für deine Antwort.

    Also Verweise sind einfach Bezugnahmen auf eine Liste von DLLs. Und was sind denn jetzt Assemblies? Addressieren Verweise jetzt Assemblies oder DLLs oder EXE-Dateien oder alles ? Kann man einen Verweis selbst anlegen, also etwa "hugo" der auf "myFunny.dll" verweist ?

    Was ist ein Zwangsverweis? Und wo wird der gesetzt?

    Und gibt es jetzt eine hierarchische Struktur der Verweise oder sind das einfach Namensvergaben, die durch einen Punkt getrennt werden.

    Also je länger ich mich damit befasse, desto mehr Fragen habe ich! Allein die Sache mit den Imports meine ich verstanden zu haben. Aber ansonsten scheint mir das alles ein ziemlicher "Verhau" zu sein ... na ... vielleicht gelingt es ja doch noch jemandem da Licht in das Dunkel zu bringen.

    Peter329 schrieb:

    Assemblies
    sind .NET-programme, also EXEn und DLLs.
    Du kannst eine .NET-Exe einer anderen .NET-Exe als Verweis hinzufügen.
    eine hierarchische Struktur
    hat Microsoft mit seinen Namespaces geschaffen, die eine wohlgeordnete innere Logik zeigen.
    Mach einfach mal eine neue Projektmappe und füge dieser Projektmappe mehrere DLLs hinzu, auf die Du zugreifen möchtest. ;)
    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!

    Peter329 schrieb:

    Im Object Explorer finde ich dann auch nur ein Display, das mir mehr Fragen als Antworten liefert.

    Unter VisualBasic finde ich jedenfalls auch nix was auf die vermaledeite "MsgBox" hinweist.
    Der ObjectExplorer hat doch eine Suche-Funktion - haste da mal "MsgBox" eingegeben?

    Und ein Zwangsverweis ist ein Verweis, den du nicht entfernen kannst. Aber das sagte ich glaub schon.