Dll Lokal Kopieren ? kurze Frage

[NReim]

Hallo ihr Guten

Ich hätte mal kurz eine kleine frage hier in die runde !

Ich bin noch nicht so lange mit VB am Zug und habe ein paar kleine fragen !

Ich schreibe momentan ein Programm in VB 2005 Express, welches mit 2 Programmen Kommuniziert EXCEL und CATIA V5 ( CAD SYSTEM ). t auch Super

Keine Panik jetzt kommen nicht die großen WIE KANN ICH DAS MACHEN fragen !

sondern:

Um mit den beiden Programmen zu kommunizieren muss ich ja auf einige DLL`s verweisen, nun ist mir aufgefallen das manche DLL`s Lokal in meinen Projekt Ordner Kopiert werden ( Die z.B. von CATIA ) und manche benötigen keine Lokale Kopie z.B. die von Excel !!

Soweit so gut
Wenn ich nun mein Programm starten möchte d.h. ich kopiere mir die EXE aus dem Release Ordner und starte sie meckert das Programm bezüglich der fehlenden DLL`s ...
Hole ich die DLLs mit dazu läuft es einwandfrei
Jetzt meine Frage ist das so korrekt das sich mein Programm die Fremd DLLs Kopiert um sie zu nutzen ?

Ich wusste zwar das mein Programm die Dlls im System benötigt aber dachte mir das die Programme (CATIA und EXCEL) halt auf dem System Installiert sein müssen so das mein Tool die Dlls von dort benutzt! ich hätte aber nicht gedacht das ich mir diese DLL`s sozusagen Kopieren muss

Mache ich etwas verkehrt, oder ist das ein reguläres vorgehen so !!

Wenn ich mein Programm nun weitergeben möchte müsste ich ja die DLL`s mitgeben, wäre das dann nicht sowas wie eine Raubkopie?

Sorry wenn ich euch mit so viel Fragen beschütte. Aber das Interessiert mich einfach!!

Mfg: Nico

 

[Spyke]

Wenn du Native DLLs verwendest (direkt als Referenz eingebunden) werden von diesen DLLs .Interop DLLs erstellt, diese dienen sozusagen als Wrapper.
Alternativ könntest du über DLLImport auf die DLLs draufzugreifen, dann hast du diese Dateien nicht.

Spyke (www.iv-interactive.de)

 

[AdmiralX]

ich dachte es gibt da so eine reihenfolge in der ein programm nach einer dll sucht, zuerst wird im ausführungsordner gesucht, dann im \system32 ordner und dann in den mit %PATH angegebenen ordnern.
wenn die dll dann nicht gefunden wird gibt eine fehlermeldung.

 

[NReim]

Wie Funktioniert das denn am Besten mit dem Importieren solcher DLLs

Angenommen ich will in mein Programm die Dll für Excel Importieren

Sorry für die Doofen Fragen, aber manchmal hängt es auch an kleinigkeiten, grade als Programmieranfänger ...

Meine Beiden Bücher Schweigen sich irgendwie bisschen über das Thema aus !

Mfg: Nico

 

[Spyke]

Für Excel müsste es schon eine Managed DLL geben
Schau dir einfach mal bei zuweisen einer neuen DLL als Verweis die ganzen Eintragungen zu .Net an, da müsste es glaube irgendwo System.Microsft.Excel oder so geben.

Und zum importieren kommt es eigentlich drauf an was du machen willst, willst du nur ein paar Funktionen aufrufen reicht ev. wirklich das Attribut DLLImport. Willst du aber Objekte aus der DLL verwenden musst du sie als Verweis anlegen.

@AdmiralX, wie bei .Net DLLs nachgeschaut wird kann ich jetzt garnicht wirklich sagen.
Vermutung: Assembly Cache dann eigener Programmordner.
Und bei den Nativen DLLs funktioniert es im Grunde auch so wie du erwähnt hast, jedoch wie oben schon geschrieben. Sobald die DLL als Verweis angelegt wird, wird automatisch diese Wrapper DLL erstellt.

Und nu schlagt mich wenn ich falsch liege

Spyke (www.iv-interactive.de)

 

[HoB-Lila]

Hallo zusammen,

also ich habe das gleiche Problem.
Ich steige derzeit von VB6 (98) auf Visual Studio 2005 um. In VB6 konnte ich die Verweise einfach einbinden und musste die DLL's dann nicht mitliefern, die Exen gingen einfach, wenn die DLL's auf dme Zielrechner vorhanden waren, sowas muss doch auch mit Visual Studio 2005 funktionieren...
Kann doch nicht sein, dass ich nun immer die bereits vorhandenen DLL's mitliefern muss...

MfG Lila

 

[Spyke]

über das Attribute DLLImport könntest du dies erreicht solange die DLL auf dem Ziel Systemr egistriert ist.
Wenn du die DLL als normale Referenz/Verweis hinzufügst musst du meines Wissens immer die *.interop.dll mit liefern. Diese DLL bildet sozusagen einen Wrapper zwischen .Net und COM.

 

[HoB-Lila]

habe DLLImport schon des öfteren gelesen, ist damit eine art include befehl gemeint und wenn ja, wie sieht der genau aus, wobei den fidne ich hier ischer im forum.

Danke erstmal, kan nich da theoretisch auch eine Umgebungsvariable als Pfad einsetzen. Diese Idee ist mir gerade gekommen und würde neue Optionen eröffnen...

Damit hätte der Mehraufwand mal Sinn...

Okay, gefunden:

<DllImport("DLLName.dll")> Private Shared FUnction...

Soweit so gut und wie binde ich so eine .tlb ein?

Thx für die gute Hilfe
MfG Lila

 

[Spyke]

die tlb registrierst du normal mit Hilfe von Regsvr32.exe und über DLLImport erstellt du sozusagen Prototypen der externen Funktionen aus der DLL die du benötigst.

[DLLImport(...)]
private static extern int MeineMethode(...)

 

[HoB-Lila]

Wenn ich die TLB im Visual Studio 2005 referenziere, dann bekomme ich wieder so ne lokale DLL in meinen Programmordner und es wäre cool, wenn ich einfachdie alte COM TLB weiter verwenden könnte, da die von einem anderen Programm kommt.

Trozdem Danke!