DLL mit Private Function

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von exc-jdbi.

    DLL mit Private Function

    Moin Moin zusammen...

    hab da mal eine generelle Verständnisfrage...
    Ich habe mir eine DLL Datei geschrieben, in der eine Cryptografische Analyse durchgeführt wird.

    Aktuell ist die Funktion jedoch in Private Function,... Muss ich das in Public Function schreiben um das ich aus meiner Anwendung drauf zugreifen kann?

    Aktuell meldet mir VBE13 folgendes in der Fehlerliste: "check_lic" ist kein Member von "crypto.crypto"

    Danke und Grüße,

    samson
    Nein! Doch! OHH!

    Guten Morgen samson

    Kommt darauf an, wie du die Dll gestaltest und nutzt. Generell gesagt müssen nur die Einstiegspunkte Public sein egal ob du Klassen hast oder nur Routinen die du als Methoden verwendest.

    Vielleicht könntest du ein bisschen Code zeigen, da würde man es sicher sofort sehen.

    Freundliche Grüsse

    exc-jdbi

    @exc-jdbi
    ok,... klingt komisch, ist aber so :D

    Hier mal der Code (leicht verändert)

    VB.NET-Quellcode

    1. Imports System.Runtime.InteropServices
    2. Imports System.Text
    3. Imports System.Security.Cryptography
    5. Public Class crypto
    7. Public Function SHA1(ByVal number As String) As String
    8. Dim ASCIIENC As New ASCIIEncoding
    9. Dim strreturn As String
    10. strreturn = vbNullString
    12. Dim bytesourcetxt() As Byte = ASCIIENC.GetBytes(number)
    13. Dim SHA1Hash As New SHA1CryptoServiceProvider
    14. Dim bytehash() As Byte = SHA1Hash.ComputeHash(bytesourcetxt)
    16. For Each b As Byte In bytehash
    17. strreturn &= b.ToString("x2")
    18. Next
    19. Return strreturn
    21. End Function
    23. Public Function check_lic(ByVal lic As String, ByVal sc As String) As String
    24. Try
    25. Dim uriString As String = "http://www.webseite.de/ext/status.php?lic=" + lic + "&sc=" + sc
    26. Dim myWebClient As New Net.WebClient
    27. myWebClient.Encoding = System.Text.Encoding.UTF8
    28. Dim ergebnis As String = myWebClient.DownloadString(uriString)
    29. Return CStr(ergebnis)
    30. Catch ex As Exception
    32. End Try
    33. End Function
    35. End Class
    Nein! Doch! OHH!

    Ich verstehe nicht recht, was du mit "verschiedenen Zugriffsarten" meinst.
    Standardmäßig würde man nun einen Verweis auf diese Dll setzen, und ihr Code wäre verfügbar wie der Code jeder anderen Dll, etwa der System.Core.Dll, der System.Windows.Forms.dll, der System.Data.Dll, ....

    Und natürlich wären nur die Public Member zugreifbar, das ist halt die Bedeutung des Schlüsselworts Public.

    Mag sein, es gibt noch andere Möglichkeiten die Dll zugreifbar zu machen, aber imo müsste man sehr gute Gründe haben, da iwas anneres zu veranstalten.

    Hallo samson

    Und ich sage VORSICHT.

    Darum wäre es interessant gewesen zu wissen wie du auf die Funktionen zugreifst. Sofern du dich nähmlich schon in der DLL befindest wäre es auch möglich mit Friends zuzugreifen.

    Fakt ist also. Das Schlüsselwort "Privat" kann nicht als Einstiegspunkt verwendet werden. Friends und Public hingegen schon. Wenn du sauberes OOP programmieren willst ist es immer strukturbedingt, und man muss wirklich alles anschauen.

    Es ist aber nie falsch das Schlüsselwort Public zu verwenden. Das liegt im Ermessen des Programmierers.

    Freundliche Grüsse

    exc-jdbi

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „exc-jdbi“ ()

    Hi
    vielleicht erklären wir dir einfach mal, wie das mit den Zugriffsmodifizierern funktioniert:
    - Private: Nur die eigene Klasse kann es verwenden (Es gibt bspw. keine Private Class, außer wenn z.B. eine Klasse in einer Klasse liegt)
    - Protected: Nur die Erben und die Klasse selbst können darauf zugreifen.
    - Friend: Nur alle Mitglieder dieser Assembly (d.h. z.B. der Programmbibliothek) können darauf zugreifen, der Member ist von außen nicht sichtbar, sondern nur für die Assembly.
    - Protected Friend: Nur Erben oder dieselbe Assembly kann auf diesen Member zugreifen
    - Public: Jeder kann darauf zugreifen ==> Auch Programme, die eine Programmbibliothek als Verweis importieren, können auf diesen Member zugreifen
    Zusätzlich gibt es noch statische Member: Shared bedeutet, dass diese losgelöst von einer Instanz sind, d.h. quasi "allgemeingültig", nicht von der Instanz abhängig (sieht man bspw. in System.IO.File).

    Es stimmt nicht, dass Public nicht auch falsch verwendet werden kann. Man sollte Public wirklich nur dort verwenden, wo der Zugriff zulässig ist.

    Viele Grüße
    ~blaze~

    Hihi - da sag ich: Vorsicht!

    Gib dich nicht mit situationsbedingten Erklärungen zufrieden. Schnapp dir ein gutes Buch (Entwickler-Ressourcen und Tools, Bücher und WebCasts ), und lerne auch alles andere, was damit zusammenhängt.
    Das OOP-Kernkonzept "Vererbung" steht in engstem Zusammenhang mit diesen Zugriffsmodifizierern.

    @~blaze~
    Darum schreibe ich ja. Es liegt im Ermessen des Programmierers. Es ist halt immer eine Frage, wie und was zugänglich gemacht werden soll. Und VB.Net (Intellisense ) macht es in dieser Hinsicht einfach nur gut. Vb.Net zeigt dir welche Möglichkeiten zur Auswahl stehen, und gibt auch sofort bekannt, sofern eine Unübereinstimmung besteht. Aber trotzdem muss man die mechanismen des Syntaxes kennen, wenn ich das so sagen darf.

    Freundliche Grüsse

    exc-jdbi