ftprequest alternative

Hallo!

Gerade bin ich dabei eine Codeunit von MS NAV 2017 auf BC-OP 16 zu übernehmen. Dabei bin ich leider an den Punkt gekommen das es die .NET für "ftprequest" nicht mehr gibt. Zumindest kann ich nichts finden und Visual Studio Code haut mir das rot um die Ohren.
Weiß evtl. jemand von euch ob es dafür eine neue .NET gibt oder ob man das anders schön regeln kann?

Wir tauschen über diesen Weg .csv Dateien zwischen NAV(BC) und einem Webshop, in beide Richtungen, aus.

Bisher habe ich von Lösungen die über ein extra FTP Programm laufen abstand genommen. Ich habe hier die befürchtung da ggf. eine Statusmeldung über ein Fehler, oder ähnliches, nicht an NAV(BC) weitergegeben wird, da diese meistens über Skripte laufen. Da könnten meines Erachtens Daten verloren gehen.

Was sagt Ihr dazu?

LG
Robert

[sweikelt]

Azure-Functions, oder vll. javascript

https://github.com/Microsoft/AL/issues/3478
https://stackoverflow.com/questions/26946684/implementing-ftp-using-javascript

Zuletzt geändert von sweikelt am 11. August 2020 07:39, insgesamt 1-mal geändert.

Hallo,

WinSCP gibt es auch als .Net Libraray.

Gruß Fiddi

Danke euch beiden.

Das mit den AZ-Function habe ich auch schon gesehen und auch das mit den Javascripts. Fand ich recht unschön. Kann mich da aber auch täuschen.

Was die WinSCP Lösung angeht hatte ich auch schon folgendes gefunden:
https://diveshboramsdnavblog.wordpress.com/2017/11/25/transferring-files-over-ftp-sftp-protocol/

Glaube so etwas in der Art wird dann wohl die Lösung werden.

Bleibe aber weiter für andere Lösungsansätze offen

Wie genau fügt man die WinSCP.dll denn hinzu? Ich habe sie in den Add-ins Ordner getan und haben den Pfad des Add-ins Ordner auch im VS-Code unter den Settings hinzugefügt.
Wenn ich nun eine Variable anlegen möchte wie
WinSCP: DotNet <irgendwas mit WinSCP>; findet er nichts.

Hallo,

ist die dll denn in dem in der settings.json angegebenen Pfad?

Gruß Fiddi

Ja.
In der Settings steht:
"al.assemblyProbingPaths": [
"./.netpackages",
"c:/windows/assembly/",
"C:/Program Files/Microsoft Dynamics 365 Business Central/160/Service/Add-ins"
]

Im letzteren Pfad ist dann ein Ordner namens "WinSCP" und dort enthalten die "WinSCPnet.dll". Ich habe mich hier nach dem Beispiel der anderen Ordnern in dem Pfad gehalten.

Gruß
Robert

Hallo,

gibt es kein intelisense, wenn du die Variable anlegst, und mit W beginnst?

Gruß Fiddi

Ja genau die kommt nicht. Deswegen gehe ich nun davon aus etwas falsch gemacht zu haben.
Hatte die DLL auch nochmal direkt in den Add-ins Ordner getan. Leider klappt auch das nicht.

Dumme Frage: in der dotnet.al ist die DLL bzw. Die Klasse eingetragen?

Keine doofe Frage. Habe ich nicht weil ich nichts davon wusste. Wo finde ich die. Google sagt mir nichts wo.

Habe mich schon gefragt wie das nun geschieht. Früher (BC 14) musste ich immer noch :
dotnet
{
assembly(System)
{
Version = '4.0.0.0';
Culture = 'neutral';
PublicKeyToken = 'b77a5c561934e089';

type("System.Net.FtpWebRequest"; DotNetFtpWebRequest) { }
...

eingeben. Das brauchte man irgendwann nicht mehr. Könntest du mir verraten wie es geht?
Danke :)

Daran hat sich nichts geändert. Voraussetzung ist target OnPrem.

OnPrem habe ich und war mir noch klar.
Aber wenn das noch genau so ist, und sich nichts geändert hat .. wie kann es sein das ich das nicht mehr so mache und es für andere dotnet Aufrufe geht.
Ok, Danke. Ich werde es mal so probieren.

Blöde Frage:
Hast du den ServiceTier zwischenzeitlich mal neu gestartet?

Gruß Fiddi

wie kann es sein das ich das nicht mehr so mache und es für andere dotnet Aufrufe geht.

andere sind vermutlich Standardklassen, die in der Basis bereits enthalten sind und deren alias du nutzt.

Einfachste Bereitstellung für DotNet Klassen als zip in der Addin-Tabelle.

Aber wenn das noch genau so ist, und sich nichts geändert hat .. wie kann es sein das ich das nicht mehr so mache und es für andere dotnet Aufrufe geht.

wenn du uns noch ein / zwei Beispiele nennen würdest, wo es bei anderen dotNet-Aufrufen geht, könnte man mal nachschauen ;)

Blöde Frage:
Hast du den ServiceTier zwischenzeitlich mal neu gestartet?

Meinst du seit dem ich die neuen dll hinzugefügt habe, oder allgmein seit dem ich die DotNet sachen nutze?

wie kann es sein das ich das nicht mehr so mache und es für andere dotnet Aufrufe geht. andere sind vermutlich Standardklassen, die in der Basis bereits enthalten sind und deren alias du nutzt.

Einfachste Bereitstellung für DotNet Klassen als zip in der Addin-Tabelle.

Kann ich mir aktull nichts drunter vorstellen. "zip in er Addin-Tabelle". Wo finde ich die?

Ich habe nachgeschaut und ich habe wirklich nirgendwo eine Assembly hinzugefügt. Dennoch funktionieren folgende DotNet:

- DotNet Path
- DotNet Array
- DotNet StreamReader
- DotNet NetworkCredential
- DotNet FileStream
- DotNet File
- DotNet Stream
- DotNet Directory
- DotNet SearchOption

Nicht mehr funktionieren:
- DotNet FtpWebRequest
- DotNet FTPWebResponse
- DotNet List

Ich habe nachgeschaut und ich habe wirklich nirgendwo eine Assembly hinzugefügt. Dennoch funktionieren folgende DotNet:

- DotNet Path
- DotNet Array
- DotNet StreamReader
- DotNet NetworkCredential
- DotNet FileStream
- DotNet File
- DotNet Stream
- DotNet Directory
- DotNet SearchOption

das könnte meiner Meinung nach daran liegen, dass Microsoft diese DotNet-Pakete in der Applikation ausliefert

Ich habe nun folgendes gemacht und alles läuft wieder.

Code:

dotnet
{
    assembly(mscorlib)
    {
        type("System.Collections.Generic.List`1"; List) { }
    }
    assembly(System)
    {
        type("System.Net.FtpWebRequest"; FtpWebRequest) { }
        type("System.Net.FtpWebResponse"; FTPWebResponse) { }
    }
    assembly(WinSCPnet)
    {
        type("WinSCP.SessionOptions"; WinSCPSessionOption) { }
        type("WinSCP.Session"; WinSCPSession) { }
    }
}

Z.B. Früher musste ich alle, auch die jetzt immer verfügbar sind, über die "System" assembly einbinden. Z.B. wurde "List" war früher auch bei System mit drin. Nun halt in "mscorlib". Zum Test habe ich auch mal "WinSCPnet" mit eingebunden. Und siehe da ;) nun kann ich auch alles dazu aufrufen.

Danke euch allen für eure Unterstützung.

Moin zusammen.

Ich muss diesen Thread noch einmal wiederbeleben.

Ich hatte seiner Zeit alles auf WinSCP umgebaut und es funktionierte über viele BC Versionen hinweg. Jetzt haben wir am WOchenende auf Version 18.5 hochgezogen und ich bekomme folgende Meldung:

Eine Instanz des folgenden .NET Framework-Objekts kann nicht erstellt werden: Montage WinSCPnet, Version=1.7.2.10905, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf, Typ WinSCP.SessionOptions.

Ich habe schon, wie hier zu sehen, ältere WinSCP Versionen probiert. Dienst mehrfach neu gestartet. An der Programmierung habe ich nichts geändert. Ich Verstehe es einfach nicht.
Das Ereigenissprotokoll vom Server sagt mir:

Message: Es wurde versucht, eine Assembly von einer Netzwerkadresse zu laden, was in früheren Versionen von .NET Framework zum Ausführen der Assembly als Sandkastenassembly geführt hätte. In dieser Version von .NET Framework wird die CAS-Richtlinie standardmäßig nicht aktiviert, dieser Ladevorgang kann daher gefährlich sein. Wenn Sie nicht beabsichtigen, durch diesen Ladevorgang eine Sandkastenassembly zu erstellen, aktivieren Sie den loadFromRemoteSources-Schalter. Weitere Informationen finden Sie unter "http://go.microsoft.com/fwlink/?LinkId=155569".

Aber ich habe keine Ahnung wo ich diesen "loadFromRemoteSources-Schalter" aktivieren kann. Auch der Link, und viele weiter von Google, konnten mir hier keine Antwort liefern.

Der Server auf dem BC läuft ist ein 2019. Und die BC Verion ist 18.5.

Kennt das jemand von euch, bzw. hat einen Ansatz für mich?

Hallo,

wie nutzt du den WinSCP.Net? Als Addin oder als installierte .Net- libaray?

Wenn du die Library im Betriebssystem installiert hast, kann ein Update von WinSCP (aktuell ist Libraray- Version 1.8....) deine Anwendung zum abstürzen bringen. Besser wäre es WinSCP (WinSCP.exe und WinSCPNet.dll) in die Addins des Service-Tiers zu legen, dann bist du sicher, mit welcher Version du arbeitest.

Gruß Fiddi

Die DLL liegt in einem Ordner im Add-Ins Verzeichnis.
Hat ja auch immer funktioniert.

Versionen hatte ich von WinSCP diverse getetestet und bei allen der selbe Fehler. BC Version schrieb ich ja 18.5

Da es jetzt seit 3 Tagen nicht lief obwohl ich nichts geändert habe, hab ich wieder alles auf WebRequest umgebaut. Wie früher auch. Das läuft nun wieder.