DLL oder eine abhängige Datei von Netzlaufwerk nicht gefunden

Hallo zusammen,

ich habe ein Problem mit einer selbstgeschriebenen c# dll das ich kurz beschrieben möchte:
Wir entwickeln hier eine Software in der Programmiersprache Gupta/Centura (schon etwas älter...)
Diese unterstützt auch die möglichkeit c# dll mit einzubinden. Jetzt ist folgendes passiert:

Wir hatte bisher immer im Programm FTP Funktionalität implementiert (über eine andere DLL) wollen diese aber durch WinSCP ersetzen (kann mehr etc.)
Da wir aber im ursprünglichen Programm möglichst wenig ändern wollen, habe ich noch eine eigene Wrapper dll in c# geschrieben, die die alte Schnittstelle möglichst genau simuliert und intern die WinSCP Befehle aufruft.
Gesagt getan, wrapper dll erstellt und eingebunden (incl. der DLLs von WinSCP) und lokal läuft alles prima.
Sobald ich aber den Ordner 1:1 auf ein Netzlaufwerk schiebe und dort versuche die Schnittstelle aufzurufen bekomme ich den Fehler dass die wrapper DLL oder ein abhängige Komponente nicht gefunden wird.
Da er den kompletten, korrekten Pfad der Wrapper DLL anzeigt, nehme ich an, dass er dann die WinSCP DLL nicht findet.
Ich habe jetzt schon einiges gegoogelt und auch schon ausprobiert
z.B.

  <runtime>
    <loadFromRemoteSources enabled="true"/>
  </runtime>

in die Config gesetzt.
aber nichts geht.

wobei ich mit gar nicht sicher bin, ob die Config bei einem Aufruf der DLL überhaupt geladen wird, schließlich ist es ja kein Programm.

Wenn hier noch jemand einen Tip für einen Neuling hätte, wäre ich sehr dankbar.

Vielen Dank

Sobald ich aber den Ordner 1:1 auf ein Netzlaufwerk schiebe und dort versuche die Schnittstelle aufzurufen bekomme ich den Fehler dass die wrapper DLL oder ein abhängige Komponente nicht gefunden wird.

Hi,
genau da liegt der Hund begraben. Das Betriebssystem schiebt gerne DLL´s einen Riegel vor, die nicht direkt auf dem PC liegen.
Zu Recht, könnte ja sonst Jeder auf das Netzlaufwerk zugreifen und die DLL durch eine schadhafte austauschen.

Also habe ich das gesamt richtig verstanden, daß die DLL (Ordner auch mit anderen Dateien), auf einem Netzlaufwerk liegt, das Programm selbst aber lokal auf den Client-Rechner?

Ich könnte mich nicht erinnern, daß das jemals irgendwer gemacht hätte, wäre auch kein Standard...

Wir haben es bei uns in unserer kleinen Firma so gemacht, daß das gesamte Programm (ausführbares und alle Abhängigkeiten) auf dem Netzlaufwerk liegt und jeder Berechtigte darauf zugreifen und starten kann.

Wäre vielleicht eine Alternative, kenn Euer Programm nicht. Zudem muß es nur einmal vorhanden sein und nicht auf jeden Klienten.

Vielleich noch die genaue Fehlermeldung hier reinstellen...

Grüße

Jedes Netzwerklaufwerk wird per default als unsichere Location deklariert. Nennt sich CAS Policy.

Über die Caspol.Exe kann einer Maschine eine Netzwerk-Location als sicher definiert werden.
Dann lädt .NET von dort auch DLLs. Ansonsten nicht.

Applikationen gehören aber sauber deployed und nicht nur auf ein Netzwerkshare geschoben.
Das macht Updates sehr umständlich.... organisatorisch nur bei sehr kleinen Firmen überhaupt anwendbar.

Übrigens wurden vor einigen Jahren sogenannte Webanwendungen erfunden, die in einem Browser verwendet werden können.
Diese sind dafür ausgelegt, von mehreren Benutzern zeitgleich verwendet zu werden.
Desktop Applikationen sind es nicht.

Hallo Abt, es stellt sich halt immer die Frage ob es sicht auszahlt, ein vorhandes älteres Programm als eine Webanwendung neu zu schreiben...

Danke erstmal für die Antworten, hier noch einige Erläuterungen:
In dem erwähnten Ordner befinden sich alle Dateien, also auch die ausführenden Exe-Dateien, die auf die DLL zugreifen.
In unserem Umfeld ist es durchaus üblich (Warenwirtschaft Mittelstand), dass es keine lokale Installation gibt, sondern alles über ein zentrales Netzlaufwerk gestartet wird, was Updates sehr einfach macht. Es wir keine Installatin auf dem Client benötigt (Thin Client etc.)

Webanwendungen sind natürlich schön, aber wenn man eine bestehende Software hat, in der mehrere dutzend Manjahre Entwicklungszeit stecken setzt man sich nicht einfach mal so hin und schreibt eine Webanwendung, die das alles ersetzt.

Caspol.ese werde ich mir mal anschauen, danke für den Hinweis.

Meine Idee war ursprünglich, ob es nicht eine Möglichkeit in der Config gibt, den Pfad zu dem Assembly gibt, habe aber nichts gefunden.

wobei ich mit gar nicht sicher bin, ob die Config bei einem Aufruf der DLL überhaupt geladen wird, schließlich ist es ja kein Programm.

Bin mir mit den Aussagen noch immer nicht ganz sicher, geht es darum, die app.config der DLL zu lesen? Wenn ja, dann schreib diese Infos in die 'ausführbare Datei'.config und nicht in die 'DLL'.config.

Meine Idee war ursprünglich, ob es nicht eine Möglichkeit in der Config gibt, den Pfad zu dem Assembly gibt, habe aber nichts gefunden.

Bitte erkläre das...

Meine Idee war ursprünglich, ob es nicht eine Möglichkeit in der Config gibt, den Pfad zu dem Assembly anzugeben, habe aber nichts gefunden.

Unterstreichung durch mich. Sollte es erklären 😉

Hi

wie schon gesagt ist die Zielsprache keine .NET Sprache, sondern Gupta/Centura. Dort gibt es keine ...exe.config oder etwas ähnliches.

Grüße

Ich gebe zu das ist nicht einfach, daher evtl noch mal als "Diagramm":

Gupta (4GL): Warenwirtschaft.exe bindet die von mir geschriebene
.NET WinSCP_Wrapper.dll ein, diese hat wiederum einen Verweis zu
.NET WinSCP.DLL

Gupta etc ist KEIN .NET o.ä. das wird über einen proprietären Wrapper unterstützt
Die Idee war eben eine z.B.

WinSCP_Wrapper.dll.config

zu erstellen, in der schon
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
steht (geht aber nicht)
und evtl noch so etwas wie assemblyBinding habe dazu aber nicht gefunden.

Danke

Evtl. sucht Gupta die DLL nicht auf dem Laufwerk, sondern im GAC. Wäre jedenfalls relativ üblich bei externem .NET Calling.
Ergo: DLL muss signiert und überall installiert werden. Da ist dann nix mehr mit Networksharing.

Wenn deine Wrapper-DLL korrekt angesprochen wird und es tatsächlich nur um die WinSCP.dll geht, dann könnte man die beiden DLLs eventuell mergen. (ILMerge)

ah, super Ideen, danke für die Hinweise, ich werde beides testen

Vielen Dank,

werde berichten, ob und was funktioniert hat.

Vorsichtig be ILMerge von fremden DLLs: das ist in 99,999% der Fällen durch die Lizenz nicht erlaubt.

Danke für den Hinweis, werde ich berücksichtigen.