Hallo,
Mein Code der Form Anwendung sieht so aus:


Meine Klassenbibiliothek sieht so aus:


Um diese Dll-Datei jetzt in seinem Programm verwenden zu können, so muss sich die Dll-Datei mit der EXE-Datei in einem Ordner befinden. Jetzt mein Problem: Wie kann man dem Programm sagen, dass sich die Dll-Datei woanders und nicht im selben Ordner, wie die EXE-Datei ist?

Dann wäre da noch ein Problem mit den Administrator-Rechten. Wie kann man diese, für das verschieben einer Dll-Datei ändern? Ist das überhaupt möglich?

MfG
Michael K.

(PS. Hi habe falsche Namen in der Form und der Class verwendet. )

Wenn Du sie dorthin kopierst, ist das nicht vonnöten.
Wenn Du die DLL so verwenden willst, dass das System sie für Dich lädt, muss sie installiert sein (das trifft für Deine DLL nicht zu) oder sie muss sich im Pfad der Exe befinden. Also kopieren.
Wenn Du sie als Assembly verwenden willst, ... aber das kriegen wir später.
Und:
Was hat der Pfad der DLL mit den merkwürdigen und inkompatiblen Codsnippets zu tun?

Okay wie macht man die Variante, dass das Programm dem System auffordert die Dll zu laden/zu verwenden.

Michael K. schrieb:

Okay wie macht man die Variante, dass ...

RodFromGermany schrieb:

das kriegen wir später.

Da fehlen Dir noch echt die Grundlagen.
Kopiere zuunächst die DLL in das Verzeichnis der anderen EXE.
Wenn Du die EXE weitergibst, muss ja der Mensch Deinen Verzeichnisbaum nachbauen, damit die DLL dann fern gefunden wird. Soll er das wirklich

Das Nachbauen des Baumes wird ein Installer erledigen. Ich stelle jetzt eine ganz dumme Frage. Die ist mir schon fast peinlich: Welches Verzeichnis, wo ist das Verzeichnis?

Michael K. schrieb:

[nicht] im selben Ordner, wie die EXE-Datei ist?

Den Ordner, den dem du die DLL nicht haben willst, meinte @RodFromGermany: ;). Aber wozu willst du das in verschiedenen Verzeichnissen haben??? Schreib den Installer halt so, dass die DLL in genau dieses Verzeichnis kopiert wird.

Der C Installer wird auch so programmiert. Aber, das Problem ist (villeicht versteht man das ja), dass die EXE-Datei die Dll-Datei nicht finden wird. Kopier mal folgendes in VB:

In einer neuen Klassenbibiliothek:



und in eine neue Windows-Forms:



Jetzt füge den Verweis der Dll-Datei hinzu und Debugge alles. Am Ende hast du ja im Output-Ordner deine EXE-Datei und die Dll-Datei, die du dem Verweis hinzugefügt hast. Um das Objekt (hier: Button1) umzubenennen und das Programm funktionsfähig zu machen muss die Dll-Datei im gleichen Ordner, wie die EXE-Datei sein. Probiere mal aus, wenn du die Dll-Datei einfach mal löscht und dann versuchst den Namen des Buttons durch einen klick zu ändern. Es erscheint eine Fehlermeldung, dass die Datei "Test.dll" nicht gefunden wurde. Also funktioniert die EXE-Datei nur im gleichen Ordner mit der Dll-Datei.
Mein Ziel ist es jetzt, dass die Dll-Datei nicht mit der EXE-Datei in einem Ordner sein muss, sondern ein im VB-Code angegebenes Ziel verfolgt und die Dll-Datei dann unter dem angegebenen Ziel findet. Die Schritte, wie man das macht, also, dass die Dll-Datei auch in andere Ordner ohne EXE-Datei platziert werden kann und das der EXE-Datei dann durch VB-Code gesagt wird, wo in welchem Ordner er die Dll-Datei findet.

Also brauch ich einfach einen Code womit man dem Programm sagt, dass sich die Dll-Datei unter Ziel so und so befindet.

Ich hoffe ich habe das jetzt einigermaßen verständlich und ohne Rechtschreibfehler erklärt (versuche nämlich diese zu vermeiden).

MfG
Michael K.

Michael K. schrieb:

Mein Ziel ist es jetzt, dass die Dll-Datei nicht mit der EXE-Datei in einem Ordner sein muss, sondern ein im VB-Code angegebenes Ziel verfolgt und die Dll-Datei dann unter dem angegebenen Ziel findet.

Das ist mir schon klar - die Frage ist nur: warum???
Aber egal, guck dir mal das hier an: support.microsoft.com/kb/837908 Ist zwar C# und Englisch, kannst du aber beides übersetzen

Warum: 30 Tage Testversion kann, wenn man den Ziel der Dll-Datei und EXE-Datei ändert wieder bei abgelaufenen 30 Tagen vollständig genutzt werden. Das möchte ich dann ja verhindern also die Dll-Datei hält vieles, was im Testversionsablauf passiert fest mit My.Settings. Bei ändern des Ziels (Beispiel: C:\Test\Test.exe) erlischt My.Settings wieder. Deswegen würde ich die Dll-Datei gerne unter System32 speichern und dem Programm auch sagen, wo die Dll-Datei im System32 liegt.

My.Settings kann der User auch - wenn er sich minimal auskennt - mit dem erstbesten Texteditor unter Appdata verändern. Da solltest du dir schon was sichereres überlegen.

@Michael K.:
Bevor Du fragst, wie man die Dll von wo anders laden kann, solltest Du Dich fragen, ob Du das überhaupt willst.
Denn: Ich möchte nicht, dass irgendein Programm im System32 Ordner herumpfuscht und mir meine Windows-Dateien zerschießt. Nebenbei würde man dafür sowieso Administratorrechte benötigen, und wenn's blöd/gut geht (je nach Sichtweise), meldet sich der Virenschutz.
Lass die Dll im Ordner der Exe. Es gibt keinen Grund das anders machen zu wollen. Denn Dein Programm wird sowieso per Installer installiert.
Das bedeutet, dass die Exe sowieso unter C:\Program Files\Ordner\ abgelegt wird. Und dort interessiert's niemanden, ob die Dll jetzt da ist oder wo anders.

Wenn Du die Exe Datei ohne Installer ausliefern würdest, dann wäre es eine Überlegung wert. Aber um das richtig zu machen fehlt Dir noch etwas an Grundlagen.


PS:
Option Strict On!
Ein Object hat keine Variable mit dem Namen Text.
Gib mal nicht einen Button, sondern z.B. die Zahl 123 an Deine Funktion. Dann knallt's.

Suchst du zufällig sowas hier

[VB.NET] Wie erstelle ich ein PlugIn System unter VB.NET (Framework 2)

Ist zwar ein Plugin System, aber die DLL muss nicht im Verzeichniss des Programmes liegen

//EDIT

Musst halt die DLL ein wenig umschreiben, damit Sie halt auf das Plugin System zutrifft, wäre
aber eine bessere Lösung als mit System32 , da dann wie oben schon gesagt wurde ein Risiko
(für dich bzw. deinem Programm) besteht, dass das Virenprogramm sich meldet!


Hoffe ich konnte dir helfen

Michael K. schrieb:

VB.NET-Quellcode

1. Public Class Test
2. Public Sub Namen_ändern(ByVal Objekt As Object, ByVal Text As String)
3. Objekt.Text = Text
4. End Sub

VB.NET-Quellcode

1. Public Class Form1
2. Dim a As New Test.Test
3. Public Sub Button1_Click(...) Handles Button1.Click
4. a.Namen_ändern("Test", Button1)
5. End Sub

Hab ich Dir nicht oben schon gesagt, dass Deine Prozeduren inkompatibel sind?
xx(String, Control) ruft auf xx(Object, String).

---

Michael K. schrieb:

Der C Installer wird auch so programmiert.

Bist Du lernresistent :?:

Okay was wäre denn jetzt die alternative es unter System32 zu speichern. Irgendwo anders? Aber wo? Wo speichert z.B. der Smart Install Maker die 30 Tage Testversion Daten. Der Smart Install Maker ist sowas mit ner Testversion. Hab auch mal versucht ne dll oder den Ordner einfach zu verschieben: Geht nicht die noch gültige/abgelaufene Testversion bleibt. Wie haben die das denn als beispiel gemacht?
Das von Seppi123 sieht interessant aus. Werde das gleich mal nachgucken.


P.S. Ich bin nicht lernresistent

Michael K. schrieb:

Wo speichert z.B. der Smart Install Maker die 30 Tage Testversion Daten.

Ist Dein Programm so wertvoll, dass dieser Aufwand lohnt?
Braucht irgendwer sonst noch diese DLL?
Kopier die DLL einfach neben die EXE und fertrig.

Hey ich mach das einfach so:



Jetzt muss ich das Programm nur noch ein bisschen sichern und fertig.

Ja mein Programm ist nicht wertvoll. Mein Ziel ist ja so ne 30 Tage Testversion. Zu 3/4 habe ich mein Ziel schon erreicht. Was mir jetzt noch fehlt ist, wie man den Namen der EXE-Datei nennt, die der Benutzer immer ändern kann also der in einem Ordner angezeigte EXE-Dateiname. Bekommt man den villeicht so: My.Application.Info.Name oder so? Ich bekomms auf jeden fall nicht raus. Villeicht wisst ihr es ja.

Habe ich dich richtig verstanden, dass du ein umbenennen der Datei verhindern willst, weil dein Programm die zugehörige Datei von My.Settings sonst nicht mehr wiederfindet, in der gespeichert ist, bis wann die Testversion gültig ist?
Wenn ja => Post #10
Wenn nein => Bitte erklär's nochmal

Ja richtig das will ich

Du kannst den Pfad verschlüsselt (base64) unter my.settings speichern.. dann legste nen hash ab in md5 (jeweils auch in Base64 form) der den String sichert... und vergleichst ihn =)
oder anstatt die dinger mittels my-Seetings zu speichern, schreibe die md5-hashes AN DAS ENDE DER EXE-DATEI (mittels binary-writer) =)

[VB 2008] Adresse einer variable in einer anderen EXE ermitteln... und mittels HEX ändern...

Was soll diese Pseudo Sicherheit bringen? Lass es doch im Programmordner, wenn der User es entfernt ist das ja sein Problem.