Probleme beim dynamischen einbinden von dll's

  • VB.NET
  • .NET 4.0

SSL ist deaktiviert! Aktivieren Sie SSL für diese Sitzung, um eine sichere Verbindung herzustellen.

Es gibt 40 Antworten in diesem Thema. Der letzte Beitrag () ist von Rattenfänger.

    Habe mal ein bsp. Projekt rausgesucht,

    das ist nur zu testzwecken gewesen und unsauber programmiert. Stellt euch vor die exe, soll dynamisch als dll über eine andere dll importiert werden. Jetzt wird als bsp. der verweis zur sldworks.dll nicht gefunden. Solidworks ist ein professionelles cad tool, das eine api anbindung hat. Hoffe das es verständlich ist :-).
    Dateien
    • Wartungstool.zip

      (1,49 MB, 7 mal heruntergeladen, zuletzt: )

    Rattenfänger schrieb:

    Hoffe das es verständlich ist
    Das genügt leider nicht, Deinen Effekt zu reproduzieren, es hagelt 55 Fehler und 24 Warnungen.
    Option Strict ist ebenfalls Off. ;(
    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).
    VB-Fragen über PN / Konversation werden ignoriert!
    Schau, ein bischen Arbeit musst DU auch reinstecken.

    ​Mach ein neues Projekt ohne jeglichen Schnick Schnack. Das Projekt soll NUR dein Aktuelle Problem enthalten. Und zwar wie du Dynamisch Controls einbindest.
    ​Mach das mal, meistens kommt man dann schnell (beim erstellen dieses Projekts) sogar selbst auf den Fehler.

    Grüße
    If _work = worktype.hard Then Me.Drink(Coffee)
    Das mit option strict off ist mir bewusst(undwollte es mit dazuschreiben, weil ich wusste das Ihr mich darauf ansprecht,lol). das war wie gesagt nur zu testzwecken wie die machbarkeit ist. Mir ist auch bewusst, das man den Code um 50% hätte reduzieren können.Desweiteren ist das ja auch nicht der code. es geht ja nur um das grundlegende prinzip. Wie kann ich die sldworks (dll) dynamisch einladen und auf sldworks verweisen um weiter auf den Objektkatalog zuzugreifen.

    Also Imports Sldworks du bist "DIM assembly as System.reflection,assembly = system.reflection.assembly.lodfile("")"

    Rattenfänger schrieb:

    es geht ja nur um das grundlegende prinzip.
    Und dafür machst Du Strict Off :?:
    Fang an und gewöhne Dir einen ordentlichen Programmierstil an, Deine zukünftigen Projekte werden es Dir danken :!:
    Und die Mitglieder im Forum auch. :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).
    VB-Fragen über PN / Konversation werden ignoriert!
    Hallo @Rattenfänger

    Ich wiederhole mich ungern. Aber.. es gibt in deinem Projekt ZIG verweise welche nicht gefunden werden können. Warum? Was haben die mit deinem Problem zu tun?
    Du hast ein Problem Assemblys zur laufzeit einzubinden. Habe ich das richtig verstanden?
    Im ganzen Projekt findet sich KEIN Code wo nur versucht wird Assemblys zu laden. Warum?

    Wenn du ein Problem hast versuche erstmal dieses genau zu isolieren. Erstelle ein neues Projekt und versuche in diesem GENAU NUR DAS. Sonst nichts.

    das ja auch nicht der code

    Whaaaat? Warum gibst du uns den dann. Langsam fühlen wir uns ver....?

    es geht ja nur um das grundlegende prinzip

    Und genau das taucht im code nicht auf. Super. :(

    Wie kann ich die sldworks (dll) dynamisch einladen

    Ich hoffe du meinst das auch so wie ich. zb. hier ein Snippet war vieleicht schon das macht was du brauchst. dotnet-snippets.de/snippet/ruf…-anhand-der-namen-auf/584

    auf den Objektkatalog zuzugreifen.

    Meinst du den Objektkatalog von VS oder meinst du Methoden der Assembly? Bitte immer versuchen korrekt auszudrücken, sonst versteht keiner was du meinst.

    PS: Ich habe dir überall wie Allgemein üblich ein Fragezeichen (?) hinter einen Satz gemacht wo eine Antwort erwartet wird.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Hallo @Rattenfänger

    Ich will mal nicht so sein. Ich habe mal ein Beispiel Anhand deines ersten Posts erstellt.

    Es gibt ein Hauptprojekt (exe) welche Assemblys laden soll. Die (zwei) Assemblys haben beide einen Verweis auf eine Bibliotek mit dem Namen Model. Dort gibt es eine Klasse Vehicle.
    Beide dlls ertellen eine andere Liste von Autos (Vehicle). Die eine erstellt VWs und die andere Audis ;)

    Wenn man eine Läd wird eine Listbox mit den Fahrzeuge befüllt.

    Anleitung: Erst die beiden Projekte mit den Test-Dlls erstellen. Rechtsklick erstellen.
    Ich habe in diese ein BostBuild Script integriert welches die dlls in das Ausgabeverzeichniss in einen Unterorder "dlls" kopiert. Von dort wird auch versucht zu laden.

    PS: Nur als schnelles Beispiel verstehen, ich habe jetzt nicht viel wert darauf gelegt das alles sauber ist.

    Grüße
    Sascha
    Dateien
    If _work = worktype.hard Then Me.Drink(Coffee)

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

    @Nofear23m Ich verstehe nicht warum du dich verarscht fühlst? Ich hatte schon geschrieben"Das liegt am Kunden nicht an mir" ist wahrscheinlich doch etwas zu ungenau gewesen die aussage. Das soll heißen, der Kunde möchte nicht das ich den Code bzw. das Projekt veröffentliche :-(.

    Desweiteren bedanke ich sehr für dein Testprojekt, nur ist die aufrufhyrachie etwas anders wie bei dir. Und ein Testprojekt zu erstellen, geht einfach nicht, da ich API-Schnittstellen andere Programme in meinem Tool nutze(SolidWorks sowie DBWorks). Der Suppert wird mir nicht helfen können, da dies eindeutig ein VB.net Problem ist.

    Zur Info:

    Der Kunde möchte ohne Dll(1) jedesmal ändern zu müssen, neue Funktionen(Dll(2) sowie Dll(3)) hinzufügen. Das Funktioniert auch sehr gut mit Solidworks Makros und auch mit funktionen die auf SolidWorks zugreifen. Jedoch habe ich probleme mit der DLL(4) die eine API-Schnittstelle zu DBW-Works ist. Der Info Text bezieht sich auf Presentatio1.png

    Hoffe das es jetzt etwas verständlicher ist :)
    Bilder
    • Presentation1.png

      53,05 kB, 1.280×720, 12 mal angesehen
    • Presentation2.jpg

      41,52 kB, 1.280×720, 9 mal angesehen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Rattenfänger“ ()

    Rattenfänger schrieb:

    Ich hatte schon geschrieben"Das liegt am Kunden nicht an mir

    Das bezog sich ja auch darauf das du kein sauberes Beispielprojekt erstellt hast. Und interessieren die anderen dlls oder Code nicht.

    Rattenfänger schrieb:

    der Kunde möchte nicht das ich den Code bzw. das Projekt veröffentliche

    ​Ist ja auch legitim. Verstehe ich.

    Rattenfänger schrieb:

    nur ist die aufrufhyrachie etwas anders wie bei dir

    ​Aber das Prinzip bleibt!! Es ist immer das selbe. WIR können nicht mit den Originalfiles testen also musst du das Prinzip einfach für dich umstricken. Fertig.

    ​Die Frage ist eher, und das wissen weder wir noch du vermutlich; sucht die dll4 wirklich im SolidWorks Ordner oder nicht? Kennst du den Code von dll4? Normalerweise wird zuerst im GAC und dann im Projektordner nach einer Assembly gesucht. So macht das .Net. Wie macht das die DLL? Das ist die Frage. Solange du das nicht weist ist das schwer. Anscheinend sucht sie ja falsch sonst hättest du die Probleme ja nicht. Oder sehe ich da jetzt was Falsch?

    ​Schau mal, wenn dein Code funktioniert mit 2 dlls und mit der dritten nicht weil diese wiederum Abhängigkeiten nicht finden kann dann liegt das vermutlich gar nicht an dir. Die frage ist: muss die dll3 evtl. an einen andere Ort verschoben werden damit diese dll4 finden kann????

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Hallo @Nofear23m

    Also dll(2) und dll(3) können dll(4) nicht aufrufen.
    Also dll(4) wird von dll(2) und dll(3) genutzt. Die dynamisch in dll(1) eingebunden sind(also dll(2) und dll(3)).

    Trotz Verweis auf die Dll(4). Hier einmal ein bsp. was ich mit verweis meine(Hier habe ich mal die Solidworks.dll hinzugefügt). Alle Dll' liegen in ein und dem selben ordner. Und der Verweis ist auf den richtigen ordner.

    Und um dich jetzt ganz zu verwirren.
    Wenn ich dll(2) und dll(3) fix in dll(1) verweise, sie bild. Kann dll(4) aus dll(2) und dll(3) aufgerufen werden. Jedoch ist das nicht vom Kunden gewünscht, da er neue funktionen hinzufügen möchte ohne dll(1) jedesmal ändern zu müssen :-).

    Gruß
    Bilder
    • Unbenannt.PNG

      13,66 kB, 393×427, 8 mal angesehen
    Und was passiert wenn du in dll(1) einen Verweis auf dll(4) hast?

    ​Ich denke langsam komme ich dahinter, kann das Problem hier allerdings nicht nachvollziehen da genau solch eine Struktur bei mir funzt.

    ​Dim cont1 As New SPS.DMS.Model.Common.ContactInfo("066412345678", EnuContactType.Phone, "Sascha")

    ​Klar, weil dll(1) ja den Verweis auf dll(4) hat.

    ​Aber, ich denke du solltest über ein Pluginsystem nachdenken, hier bist du zum einen flexibler, zum anderen Typsicher und hast auch mehr Möglichkeiten was dein Vorhaben betrifft.
    Hier ein wie ich finde super einstieg: codeproject.com/Articles/10523…le-Plugin-System-with-NET

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Test1: Ja das habe ich auch schon versucht(und hat nicht funktioniert). Falls es funktioniert hätte: müsste der Kunde sobald er eine neue dll einsetzt, diese in dll1 registrieren(darauf verweisen), was er ja auch nicht soll bzw. will.
    Test2: Dll(4) Dynamisch in Dll(1) einbinden. hat auch nicht funktioniert. Hier hätte ich noch diese als angehängte dynamisch einlesen können.
    Test3: Dll(4) Dynamisch in Dll(2) und Dll(3) einbinden. hat auch nicht funktioniert.
    Test4: Dll(4) in den ordner verschieben wo gesucht wird. Hat funktioniert , jedoch nicht gewünscht, da die dateien auf dem server liegen bleiben soll und der admin die dll's nicht auf jeden rechner lokal kopieren will.

    wie gesagt. Dll(4) ist kein COM Objekt und auch nicht Registriert.

    Schau mir den link gleich mal in ruhe an :-).

    Rattenfänger schrieb:

    Test4: Dll(4) in den ordner verschieben wo gesucht wird. Hat funktioniert , jedoch nicht gewünscht

    Aja, und jetzt?

    Rattenfänger schrieb:

    Falls es funktioniert hätte: müsste der Kunde sobald er eine neue dll einsetzt, diese in dll1 registrieren(darauf verweisen), was er ja auch nicht soll bzw. will.

    Warum? Wenn diese dynamisch eingebunden wird sind die Funktionsnamen vorgegeben (da ja dll1 nicht geändert wird bleiben die ja auch gleich) warum müsste er dann dll1 "registrieren".
    Was hast du eigentlich mit deinem registrieren? Wenn ich Assemblys dynamisch einbinde muss ich nix registrieren! Was soll ich registrieren. Im GAC? Wozu wenn du den Pfad angibst?

    Etwa schwer dir zu helfen, ich verstehe das gewisse Dinge untersagt sind, aber einen Verweis auf eine Assembly im Netwerk ist nicht mal direkt gut. Das fällt dir sowieso auf den Kopf, sei froh das es jetzt schon ist und nicht später.
    Das wird so wie du dir das vorstellst (meiner Meinung nach) nicht funktionieren.

    Ich habe dir alle meine Infos gegeben. Mehr kann ich nicht machen. Leider.
    Hast du über das Pluginsystem überhaupt mal nachgedacht oder hast du den Link gar nicht geöffnet?

    Grüße
    If _work = worktype.hard Then Me.Drink(Coffee)
    Aja, und jetzt?​

    Weil der Kunde die dll nicht lokal bei den Usern reinkopieren möchte.

    ​Warum? Wenn diese dynamisch eingebunden wird sind die Funktionsnamen vorgegeben (da ja dll1 nicht geändert wird bleiben die ja auch gleich) warum müsste er dann dll1 "registrieren".Was hast du eigentlich mit deinem registrieren? Wenn ich Assemblys dynamisch einbinde muss ich nix registrieren! Was soll ich registrieren. Im GAC? Wozu wenn du den Pfad angibst?

    Es geht hier nur um dll(4),dll(2), dll(3) sowie zukünftige funktionen sollen nicht registriertwerden. dll(1) muss lokal registriert sein, da es ein Menue addin in SolidWorks ist und nicht anders eingebunden werden kann.
    Was die dll(4) angeht, bin ich der meinung wenn sie in Windows registriert ist mit Pfad könnte Sie evtl gefunden werden, aber das habe ich auch schon getestet und hat nicht funktioniert(ist ja sowieso nicht gewünscht) :-).

    Etwa schwer dir zu helfen, ich verstehe das gewisse Dinge untersagt sind, aber einen Verweis auf eine Assembly im Netwerk ist nicht mal direkt gut. Das fällt dir sowieso auf den Kopf, sei froh das es jetzt schon ist und nicht später.Das wird so wie du dir das vorstellst (meiner Meinung nach) nicht funktionieren.​

    Es funktioniert, nur halt die eine Dll(4) (API zugriff für DBWorks), da diese kein COM objekt. Wenn ich bsp. die Dll von excel(Microsoft.office.14 heist die glaube ich) nehme habe ich keine Probleme, das funktioniert. Ist ja auch logisch die liegt Lokal, ist eine COM DLL und in windows registriert.

    ​Ich habe dir alle meine Infos gegeben. Mehr kann ich nicht machen. Leider.

    Super ich danke dir auch sehr dafür :-)! Thanks.

    ​Hast du über das Pluginsystem überhaupt mal nachgedacht oder hast du den Link gar nicht geöffnet?

    Ja habe vorhin kurz reingeschaut, möchte mir das aber in ruhe anschauen und austesten und erstmal versuchen es selbst zu verstehen, bevor ich fragen raushaue :)

    Gruß
    Hallo

    Was mir noch einfallen würde, wäre das du die dll4 im GAC registrierst. Aber auch hierbei wird eine Lokale kopie im GAC Pfad hinterlegt.
    Ist das nicht gewünscht (wie so vieles in deinem Fall) wird das wohl nichts werden. Selbst bei COM muss meines wissens nach die Bibliothek lokal verfüber sein.

    Ich nichts davon gewünscht sieht es wohl schlecht aus. Was der Rechner nicht findet damit kann er auch nichts machen. Das Prinzip ist ja einfach.
    Bei diesen Limitierungen würde es mich wundern wenn du eine Lösung findest, würde mich aber natürlich für dich freuen.

    Ich hoffe du findest eine Lösung.

    PS: Warst du beim erstellen des Lastenheftes dabei? Ich hoffe das du dem Kunden nicht versprochen hast das du das mit diesem Umfang an Limitierung machen kannst.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)

    Nofear23m schrieb:

    Selbst bei COM muss meines wissens nach die Bibliothek lokal verfüber sein.
    Wenn Du eine COM-Komponente als Verweis hinzufügst, generiert das Studio eine XXX.Interop.dll.
    Das ist eine Wrapper-DLL, die lokal vorhanden sein muss und ins Projekt eingebunden wird.
    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).
    VB-Fragen über PN / Konversation werden ignoriert!
    Hallo Sascha,

    ja er möchte die dll's auf dem server. Ich erstell mal am WE ein kleines bsp. Tool mit der dll. Die ich dann hochlade :-).

    Lastenheft gibt es zum glück nicht :-). Ich möchte dem CAD-Admin(Er ist Konstrukteur) die Arbeit so gut es geht erleichtern, damit er nicht soviele querverweise(also hier was ändern und dann muss ich da noch was ändern) hat. Die Arbeit mit dem PDM System und der einrichtung ist schon komplex genug. Und da kann man beim ändern von nur kleinen Codes doch schon durcheinander kommen. Desweiteren muss er ja auch noch konstruieren und er ist über jede Erleichterung und Automatisierung dankbar :-).

    Gruß

    Zeljko

    Rattenfänger schrieb:

    ja er möchte die dll's auf dem server.
    Er sollte die DLL da hin bekommen, wo es funktioniert.
    Wenn es fern so nicht geht, dann geht es lokal und feddich.
    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).
    VB-Fragen über PN / Konversation werden ignoriert!
    Das blöde ist, die dll müsste in einen ordner der überhaupt nicht zur dll passt. Ich sehe es so, bei 99% der meisten api-anbindungen wird es funktionieren. Also Excel,Word,Outlook,SolidWorks andere PDM Systeme.

    Das PDM-System ist schon sehr alt,glaube eine Version 2009-2010. Die neuen Versionen werden sicher schon einen Fix haben, da die auch weg von VB6 und VBscript wollen, und immer mehr vb.net implemente bevorzugen.
    Denn wie gesagt, die besagte dll ist die api schnittstelle zum PDM-system, die kurioserweise nicht lokal installiert wird, sondern für diese Version beim Support(zwischen händler) anfragen muss :-).
    @Rattenfänger Und wenn Du eine lokal Zwischen-DLL schreibst, die diese ferne DLL wrappt?
    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).
    VB-Fragen über PN / Konversation werden ignoriert!