DLLs in Resourcen einbinden & Verweis darauf

    • VB.NET

    Es gibt 19 Antworten in diesem Thema. Der letzte Beitrag () ist von Immortel.

      DLLs in Resourcen einbinden & Verweis darauf

      DLL in Resourcen einbinden

      Hi,
      ich habe mich letztens gefragt ob ich nicht eine *.dll Datei in die Resourcen einbinden könnte, und einen Verweis darauf hinzufügen könnte, um sie nicht extern weitergeben zu müssen.
      Und so gehts:

      1.Schritt

      Fügt wie gewohnt ein Verweis auf die DLL hinzu.
      2.Schritt
      Bindet die dll in die Resourcen ein. ACHTUNG: Den Namen so lassen, wie er ist!
      3.Schritt
      Geht im Projektmappen-Explorer "My Project", Wechselt in die Registerkarte "Anwendung", scrollt runter und klickt auf "Anwendungsereignisse anzeigen"
      4. Schritt
      Schreibt in der erscheinenden Klasse folgenden Code:

      VB.NET-Quellcode

      1. Private WithEvents Domaene As AppDomain = AppDomain.CurrentDomain
      2. Private Function Domaene_AssemblyResolve(ByVal sender As Object, ByVal args As System.ResolveEventArgs) As System.Reflection.Assembly Handles Domaene.AssemblyResolve
      3. If args.Name.Contains("NamederDLL") Then
      4. Return System.Reflection.Assembly.Load(My.Resources.NamederDLL)
      5. Else
      6. Return Nothing
      7. End If
      8. End Function

      Einfach für NamederDLL den Namen eurer DLL eingeben (ohne ".dll") :P

      Danke an den freundlichen Hinweis von Viktor S.: Dieser Code funktioniert nur mit .NET-DLL's, nicht mit DLL's die mit C++ vorkompiliert wurden usw.


      Achtung: Vor dem einkompilieren beachtet bitte die Lizenzbedingungen der jeweiligen DLL. Bei manchen DLL's ist das einkompilieren nicht gestattet. Fragt ggf. beim Autor nach!
      --- Zurzeit inaktiv ---

      Dieser Beitrag wurde bereits 13 mal editiert, zuletzt von „Live“ () aus folgendem Grund: VB.NET Tag gesetzt, da zu VB2003, VB2005, VB2008 und VB2010 kompatibel.

      und warum nicht einfach wie immer einen verweis drauf erstellen und anschließend (nach dem releasen) alle assemblys zussammen mergen?

      entweder manuell per consolentool von microsoft
      microsoft.com/downloads/en/det…4ae6a939b0&displaylang=en

      oder bequem per mausclick mit hilfe einer GUI
      ilmergegui.codeplex.com/

      FuFu^^ schrieb:

      und warum nicht einfach wie immer einen verweis drauf erstellen und anschließend (nach dem releasen) alle assemblys zussammen mergen?

      entweder manuell per consolentool von microsoft
      microsoft.com/downloads/en/det…4ae6a939b0&displaylang=en

      oder bequem per mausclick mit hilfe einer GUI
      ilmergegui.codeplex.com/
      ...oder einfach ohne tool wie oben :)
      --- Zurzeit inaktiv ---
      Ich habe auf diese Weise auch schon öfter eine DLL-Datei eingebunden. Man muss trotzdem noch die DLL-Datei als Verweis hinzufügen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

      Infinity schrieb:

      Ich habe auf diese Weise auch schon öfter eine DLL-Datei eingebunden. Man muss trotzdem noch die DLL-Datei als Verweis hinzufügen.

      genau so ist es... du fügst einen Veweis auf die DLL an ihrem Speicherort hinzu und dann meinen Code xD
      --- Zurzeit inaktiv ---
      Klar darf sie beim Testen mitkopiert werden, aber sie wird nicht benötigt. Außerdem muss dort stehen als Lokale Kopie = True, denn sonst erwartet dein Programm das jeder Benutzer die DLL bei sich auf dem Computer und registriert hat (so das .Net halt weiß woher es sie nehmen muss).
      Ich habe alles wie beschrieben probiert, bei mir kommt aber immer folgender Fehler, wenn ich die Exe aus dem Debug-Ordner wo anders hin kopiere und dort starte:
      System.IO.FileLoadException: Nicht verifizierbarer Code hat die Richtlinienüberprüfung nicht bestanden.

      Wenn ich sie im richtigen Ordner starte läuft alles natürlich richtig.
      Weiß jemand wieso und wie ich das beheben kann?
      Funzt nich die DLL muss dennoch mit verschickt werden

      Ich will die MySql.dll reinpacken um die nich immer mit zu verschicken

      Hi
      Ich würde das eigentlich über eine XML-Datei machen, da man dadurch ähnliche Namen ausschließt. Einfach den Assembly-Namen vollständig angeben (kann man z.B. über System.Reflection.Assembly.GetName() und FullName herausfinden). Den speicherst du dann in einer Xml-Datei mit z.B. dem folgenden Aufbau:

      XML-Quellcode

      1. <resourceAssemblies>
      2. <assembly name="mscorlib" version="4.0.0.0", culture="de-DE" token="b77a5c561934e089" resourceName="mscorlib"/>
      3. <assembly name="mylib" version="4.0.0.0", culture="de-DE" token="a1b3c3d7e" resourceName="mylib"/>
      4. </resourceAssemblies>

      Beim Laden der Assemblies gibst gehst du halt einfach alle assembly-Einträge des Xml-Dokuments durch und speicherst die Werte so, dass sie verwaltbar sind. Beim Aufruf von AssemblyResolve kannst du dann einfach den Assembly-Namen der in der Name-Eigenschaft der übergebenen EventArgs definiert wurde mit den Namen in der Xml-Datei vergleichen und die benötigte Referenz aus den Daten laden. Oder du gehst halt über den ResourceManager vor: My.Resources.Resources.ResourceManager, was aber weniger schön und sicher ist, wie die Xml-Variante.

      Gruß
      ~blaze~

      DLLs in Resourcen einbinden & Verweis darauf

      In Ergänzung zum ursprünglichen Tipp, nachstehend, wie das mit zwei (oder mehr) DLL's funktionieren könnte.

      Bei mir hat es folgendermassen geklappt (ausgehend von der Anleitung, hier im ersten Beitrag).

      Dann unter "4. Schritt" soll es so aussehen:

      Quellcode

      1. Private WithEvents Domaene As AppDomain = AppDomain.CurrentDomain
      2. Private Function Domaene_AssemblyResolve(ByVal sender As Object, ByVal args As System.ResolveEventArgs) As System.Reflection.Assembly Handles Domaene.AssemblyResolve
      3. If args.Name.Contains("Dateiname.DLLEins") Then
      4. Return System.Reflection.Assembly.Load(My.Resources.Dateiname_DLLEins)
      5. ElseIf args.Name.Contains("Dateiname.DLLZwei") Then
      6. Return System.Reflection.Assembly.Load(My.Resources.Dateiname_DLLZwei)
      7. Else
      8. Return Nothing
      9. End If
      10. End Function


      Zu beachten ist ausserdem, dass der Name der jeweiligen DLL auf der "IF..."-Zeile mit einem Punkt (".") geschrieben werden muss, also so, wie sie auch physikalisch vorhanden ist. Dahingegen wird sie auf der danach folgenden "Return..."-Zeile mit Unterstrich ("_") geschrieben, und zwar so, wie sie in den Ressourcen eingetragen wurde. Denn beim Einkopieren wurde dort ein Punkt durch einen Unterstrich ersetzt. So jedenfall meine Erfahrung.

      Dass eine zweite DLL mit einem "Else if..." anzufügen ist, meine ich, irgend wo mal gelesen zu haben. Hingegen die Sache mit den Punkten und Unterstrichen ist für andere hoffentlich auch hilfreich.
      Hoi zusammen,

      eigentlich würde ich gerne diese funktion nutzten um eine DLL ins Projekt einzubinden, leider funktioniert dies nicht bei der externen "ComponentFactory.Krypton.Toolkit" DLL von ComponentFactory.

      Eigentlich glaube ich alles richtig eingefügt zu haben und auch den Code richtig geschrieben zu haben:

      VB.NET-Quellcode

      1. Private WithEvents Domaene As AppDomain = AppDomain.CurrentDomain
      2. Private Function Domaene_AssemblyResolve(ByVal sender As Object, ByVal args As System.ResolveEventArgs) As System.Reflection.Assembly Handles Domaene.AssemblyResolve
      3. If args.Name.Contains("ComponentFactory.Krypton.Toolkit") Then
      4. Return System.Reflection.Assembly.Load(My.Resources.ComponentFactory_Krypton_Toolkit)
      5. Else
      6. Return Nothing
      7. End If
      8. End Function


      Ich habe hier gelesen, das C++ Kompilierte nicht funktionieren.
      Ist jetzt die frage, mit was ComponentFactory die dll gebaut hat. Weiß das einer? Oder vllt. hat sogar jemand schon einen Trick wie es doch funktioniert?

      Die Fehlermeldung die auftaucht, sobald ich das Programm starten möchte liegt hier als Screenshot vor.
      Bilder
      • ComponentFactory_DLL_Fehler.jpg

        321,37 kB, 1.632×573, 393 mal angesehen