Hello Rick !

I have a problem with newest Renci.SshNet.dll and wwDotNetBridge.dll on doing a sFTP-Upload.
This is the error-message of my error-handler:

This is the code with the problem: Load in wwSFTP.prg:

With older versions Renci.SshNet.dll and wwDotNetBridge.dll it works (7.33).

With the newset versions of Renci.SshNet.dll and wwDotNetBridge.dll no oSFTP-Object ist created (8.1)

I use the same code and exe and only change the dlls.

Can you help?

Just double checked here and it's working for me...

A quick test you can do is open up wwSftpClient.prg uncomment the test block at the top and run those commands. It's not going to work unless you install an SFTP server locally, but it should load and give you a failure message like Unable to connect to server at....

Based on what you show my guess is that the DLL is not being found. Perhaps path was changed or something along those lines?

Also make sure you have the latest wwDotnetBridge. When wwSftpClient was originally shipped I referenced a newer version of the SSH.NET library which had a bunch of additional dependencies and then switched to an older version that is self-contained. It's possible that you have that short lived version of wwDotnetBridge.dll that references the wrong version.

You can pick up the latest version from here (the one I just used for testing):

https://west-wind.com/files/WebConnectionExperimental.zip

+++ Rick ---

Hello Rick !

A quick test you can do is open up wwSftpClient.prg uncomment the test block at the top and run those commands. It's not going to work unless you install an SFTP server locally, but it should load and give you a failure message like Unable to connect to server at....

This works

Based on what you show my guess is that the DLL is not being found. Perhaps path was changed or something along those lines?

To be clear again: I start the EXE with the two older DLLs and the sFTP upload works. I close the EXE, replace the old DLLs with the newer DLLs and start the same EXE again. When trying to create the oSFTP object, the error shown occurs.

Also make sure you have the latest wwDotnetBridge. When wwSftpClient was originally shipped I referenced a newer version of the SSH.NET library which had a bunch of additional dependencies and then switched to an older version that is self-contained. It's possible that you have that short lived version of wwDotnetBridge.dll that references the wrong version. You can pick up the latest version from here (the one I just used for testing): https://west-wind.com/files/WebConnectionExperimental.zip

I used Your wwDotNetBridge.dll, wwDotnetBridge.PRG and wwsftpclient.PRG from the zip-file in my project and build a new EXE.
Unfortunately the same error occurs again.

Program environment:
The DDLs are not located next to the EXE but in the Class subdirectory.
To test I put Renci.SshNet.dll next to the EXE, but the same error message came up again.

For verification the DLLs have to be visible to the FoxPro path (FULLPATH()) (sounds like that's the case though).

I can't duplicate what you're describing. I've double checked to make sure that the current build does not have any extra dependencies - the renci DLL is self-contained so there are no other dependencies.

This is from minimal build output in a Console app (ie. no other dependencies):

When it fails does it fail on loading, or does it fail when you perform a specific task?

Another thing: Are you loading the DLL from a network location? If so make sure to enable network access for .NET in the yourapp.exe.config file.

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

If all fails, try to create a repro scenario that's outside of your app but using those same DLLs and pathing setup. Something along the lines of the sample code at the top of wwSftpClient.prg. You can use the Rebex SFTP server (it's a tiny self-contained exe) and set up that sample by creating a data folder below the Rebex installation folder.

As I said I did switch to a newer version of Renci.SSH, but it's working with no issue on my end, so it can't be a dependency issue.

I've also updated the WebConnectionExperimental file one more time and added in all the DLL dependencies that the build output produces for wwDotnetBridge - IOW, this is the straight from the source dependency list (which AFAIK matches what ships with Web Connection and the client tools in v8.1).

+++ Rick ---

To test I've created a self-contained folder along with an EXE project. You can modify the FTP locations to customize for your server or a local copy of your Rebex server - or just run as is and it should get you to that failure to connect message. If you get there the Renci.SSH.dll loaded (which is all that should be required).

https://west-wind.com/files/wwsftptest.zip

+++ Rick ---

Hello Rick !

When it fails does it fail on loading, or does it fail when you perform a specific task?

It fails in FUNCTION Load:

IF ISNULL(THIS.oBridge)
	THIS.oBridge = GetwwDotnetBridge()
ENDIF

*-- THIS.oBridge is an Object

THIS.oFtpClient = THIS.oBridge.CreateInstance("Westwind.WebConnection.wwSftpFtpClient")

*-- THIS.oFtpClient isn't created

FUNCTION CreateInstance(lcClass,lvParm1, lvParm2, lvParm3, lvParm4, lvParm5)
...
    CASE lnParmCount = 1 
    	loObject = loBridge.CreateInstance(lcClass)

*-- loObject isn't created

Another thing: Are you loading the DLL from a network location? If so make sure to enable network access for .NET in the yourapp.exe.config file.

The customer has the program directory on the network, on my developper-machine it is on the local-partition D:
On both configurations, the same error message came up.

And yes, a yourapp.exe.config is available

To test I've created a self-contained folder along with an EXE project. You can modify the FTP locations to customize for your server or a local copy of your Rebex server - or just run as is and it should get you to that failure to connect message. If you get there the Renci.SSH.dll loaded (which is all that should be required).

This works for me 😃

If all fails, try to create a repro scenario that's outside of your app but using those same DLLs and pathing setup.

Yes, unfortunately that will take a few days.

Thank you for your support so far; The tip with the Rebex SFTP server is very useful.

Ok so if my sample works, then there's nothing wrong with the library per se, but it's your environment setup.

So my guess it has to do with the network setup. Can you try running the sample the same way you're running the actual application (off the network)? Does that work?

+++ Rick ---

Hello Rick !

Ok so if my sample works, then there's nothing wrong with the library per se, but it's your environment setup.

It looks like this.

However, it is strange that it works like this with the two old DLLs.
And just by replacing the two DLLs it doesn't work anymore...

So my guess it has to do with the network setup. Can you try running the sample the same way you're running the actual application (off the network)? Does that work?

HPG:

The customer has the program directory on the network, on my developper-machine it is on the local-partition D:

No, running it locally also produces exactly the same error.
And the EXE is also executed in the development directory, where there should be no missing classes, PRGs, DLLs, etc. at runtime.

If my sample works there's nothing wrong with the libraries, and the issue is related to your environment setup.

I'm pretty sure this has something to do with loading from the network and potentially with the DLLs being blocked. If possible try running the application directly from the machine it's hosted on or from another non-networked machine - that'll tell you if it's a network security policy issue.

An alternative test for this is:

Try to run my sample from the network in the same way you are running the full application.

If that fails there's something that causing the secondary assembly not to load. The yourapp.exe.config should fix any network load issues. But it could also be the DLL might need to be unblocked (copied from an unsafe network region (ie. downloaded from internet and directly copied)).

+++ Rick ---

Hello Rick !

I used ProcessMonitor to examine the processes with the old and new DLLs (Renci.SshNet.dll and wwDotNetBridge.dll).
The test was performed locally, not from network.

There are two differences in access to Renci.SshNet.dll and wwDotNetBridge.dll.
Old DLLs

New DLLs

The two logs for the test are in Logfile_sftp_ok.CSV (sFTP is working) and Logfile_sftp_nok.CSV (sFTP is not working)
LogFiles.zip

There are differences in line 999 and 2546/2551 (see also in the screenshot)

Maybe this will help get closer to the cause.

If that fails there's something that causing the secondary assembly not to load. The yourapp.exe.config should fix any network load issues. But it could also be the DLL might need to be unblocked (copied from an unsafe network region (ie. downloaded from internet and directly copied)).

All dlls are unzipped locally from your wwclient-7.33.0.zip and from your wwClient-8.1.0.zip.

Can you try running your failing app on a local drive to validate that this is a network permissions issue?

The INVALID_DEVICE error seems to point at a file access issue.

Also - try manually unblocking the wwDotnetBridge and Renci dlls.

• Unable to Load CLR Instance Error

And along the same lines run the wwSftpTest.exe sample in the location where your application EXE is failing.

+++ Rick ---

Hello Rick !

The test was performed locally, not from network.

Can you try running your failing app on a local drive to validate that this is a network permissions issue?

In my last answer I wrote in the second line: The test was performed locally, not from network

Also - try manually unblocking the wwDotnetBridge and Renci dlls.

KDV2000.exe.config is in the same directory as KDV2000.exe

I will unblock the wwdotnetbridge.dll and try again.

FWIW, I just copied my test server that downloads and uploads some files and gets a directory listing, with the binaries sitting on a networked server.

This works for me...

There's something different in your environment that's causing this to fail I think, but I'm not sure what it is.

There was one recent change that was made, related to how wwipstuff.dll (and CoreClr) are loaded that pin the DLL in memory so it doesn't unload modules. AFAIK that's the only change that's occurred since older versions. But I don't see how that would affect permissions in any way and as my test seems to indicate it certainly does work with binaries loaded completely over the network.

Please test this same code on your network so we can have a common baseline to compare.

+++ Rick ---

Hello Rick !

First of all, thank you for your perseverance 😃

I do a network-test with my application.

the configuration: Windows 11 23H2 in a virtual machine under VMware without VFP9 runtime installed.
Mapped drive on a Synology NAS with the application Kdv2024-12-16.exe and Kdv2024-12-16.exe.config.
Next to the EXE is the VFP runtime and the westwind dlls are in the CLASS subdirectory.
The sFTP upload works with the old DDLs

but not with the new ones.

The logfiles for the network-test:
Logfiles_Network.zip

I compared the log files and found differences in line 2450.
When the sFTP upload is running, the Renci.SshNet.dll is searched for in the registry.

If the sFTP upload fails, the application wants to open System.xml.ni.dll.

Hello Rick !

I have now tried all points from Unable to load CLR Instance Error

• Loading from a Network Location
  MyApp.exe.config is available => no change, sFTP upload is not running

• Blocked .NET DLLs: wwDotnetBridge.dll
  The CheckBox/CommandButton Unblock is not present in either the old or the new dll.
  Unblock-File -Path '.\wwdotnetbridge.dll' doesn't change anything

• wwDotnetBridge.dll and wwIPstuff.dll not Found
  SET PATH TO CLASS ADDITIVE is set

• .NET Runtime or requested .NET Runtime Version not installed
  

  

  
  

• Older OS Versions: I test von Windows 10 and Windows 11

Hello Hans-Peter,

this can be a permission (ACL) issue. In both cases the DLL is first opened with Read and Delete permissions, then with Read permissions. The file that is not working is doing an extra check on file and volume attributes after the first open attempt. What happens if you rename the DLL that is not working and run this line:

STRTOFILE(FILETOSTR('Renci.SshNet.dll_renamed'), 'Renci.SshNet.dll')

This should create a new file with default permissions, default attributes and no hidden NTFS streams.

If that isn't working, check if you have a virus scanner that is excluding specific versions of a file that you have white listed before. Some scanners do not just rely on the file name but also create a hash or a hidden signature in an NTFS stream (Kaspersky).

Regarding storing these DLLs in classes instead of the EXE folder. I really had lots of troubles with that. .NET framework uses a different load context for files that are loaded from a specific location instead of the default and probing paths. That might be a problem, if another DLL that is located in the application folder has a dependency on wwDotNetBridge or any DLL loaded through DNB. In my case I end up with random errors that a DLL or a dependency can't be loaded that is already loaded and has been used.

This should be wwDotNetBridge.dll instead of Renci.SshNet.dll... Thought I changed this before posting, but apparently it didn't stick.

If you are still running into the problem, can you download Fusion++ from the Release tab on https://github.com/awaescher/Fusion? When you start the Application it shows a recording button. Press that button, run your application up to the point of failure, press the button again and post the generated log files.

This tool monitors the dependency resolution process of .NET and might (just might) point to a reason for the problem in case it's not the difference in the ProcMon log, but something later up the chain. I wouldn't exclude this, because ProcMon shows that the DLL is still opened OK. Windows is doing Internet Zone checks and all other kind of stuff afterwards.

Hello Christoph !

What happens if you rename the DLL that is not working and run this line:

STRTOFILE(FILETOSTR('Renci.SshNet.dll_renamed'), 'Renci.SshNet.dll')

The same error occurs.
I tried with Renci and wwdotnetbridge.

If that isn't working, check if you have a virus scanner that is excluding specific versions of a file that you have white listed before.

Only windows defender is installed.
I have deactived windows defender => same error 😦

Regarding storing these DLLs in classes instead of the EXE folder.

Even if I copied all westwind-DLLs next to the exe, the same error occurs.

If you are still running into the problem, can you download Fusion++

sFTP is running - old DLLs

sFTP is not running - new DLLs

Both logs are in Fusion++_v1.zip

The only differences seem to be that the working version loads wwDotNetBridge.dll 7.33 instead of 8.1 and that the working version continues to load these four DLLs that the non-working version is not loading:

• Microsoft.CSharp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
• mscorlib.resources, Version=4.0.0.0, Culture=de, PublicKeyToken=b77a5c561934e089
• Renci.SshNet, Version=2020.0.2.0, Culture=neutral, PublicKeyToken=1cee9f8bde3db106
• System.Dynamic, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

That might be because wwDotNetBridge just never gets to the point due to a previous error.

Hans Peter,

Your Fusion log for the new DLL stops when loading wwDotnetBridge.dll. Does it fail on load? Or when calling the sftp functions.

I guess the first issue should be is determining where the error actually occurs. What are you doing to trigger this code?

Does wwDotnetBridge work at all - ie. if you call oBridge.GetDotnetVerion() does that work in your code?

And what about the sample I sent - you never answered if you got that to run. It's possible there's something related to the application or what the application is loading that's having an impact here.

We need to pin this down to the simplest thing possible and having a simple EXE that does nothing but what we're looking for is the only reliable way we can start to track this down so we're all looking at the same thing.

As I said my sample works for me both local and when all files are loaded across the network. I think Christof also said that works for him (private msg) but I wasn't clear if that's with the exact same version files I had set up in the sample as the ones in the original release of West Wind Client Tools may have had an issue.

+++ Rick ---

Hello Rick !

Your Fusion log for the new DLL stops when loading wwDotnetBridge.dll. Does it fail on load? Or when calling the sftp functions.

With

THIS.oBridge = GetwwDotnetBridge()

i get an object

It fail when calling

THIS.oBridge.CreateInstance()

No object was created.

Please look at my first message.

I guess the first issue should be is determining where the error actually occurs. What are you doing to trigger this code?

loSFTP = CREATEOBJECT( 'wwSFTP' )

Does wwDotnetBridge work at all - ie. if you call oBridge.GetDotnetVerion() does that work in your code?

Yes
I call

THIS.oBridge.GetDotnetVersion()

after

THIS.oBridge = GetwwDotnetBridge()

and get
wwDotnetBridge Version : 8.1.0.0
Release : West Wind Commercial Release
wwDotnetBridge Location : D:\PROJEKT\VFP9\BKI\KDVDEV\KDV\CLASS\WWDOTNETBRIDGE.dll
.NET Version (official) : 4.0.30319.42000
.NET Version (simplified): 4.8.1
.NET Version (Release) : 533325
Windows Version : 6.2.9200.0 - Release: 2009

And what about the sample I sent - you never answered if you got that to run.

Do you mean the test-version from Dec 16, 2024 @ 09:48am or from Dec 10, 2024 @ 09:52pm?

Your https://west-wind.com/files/wwsftptest.zip from Dec 10 is working
Please see https://support.west-wind.com/Thread7280CGE0Q.wwt#72A00ULT9

I try to create an sample.exe.

Hello Rick !

We need to pin this down to the simplest thing possible and having a simple EXE that does nothing but what we're looking for is the only reliable way we can start to track this down so we're all looking at the same thing.

I build a test-project and tested with Rebex-server; you can download the project here:
KDVTest_03.7z

Test by pressing Aktivieren

In the class-subdirectory are the DLLs.
Try with the DLLs from subdirectory OK => sFTP is running
Try with the DLLs from subdirectory NOK => sFTP is not running

Hans Peter,

So I had a quick look at your sample. First off I can duplicate what you see with the error message when I run your application both as an EXE and from within FoxPro's IDE. In both cases this fails.

Here's what I did to see what is going on:

• Ran your EXE from the Fox IDE in the folder location and it fails
• In the same VFP session, I manually create wwDotnetBridge and an instance of wwSftpClient
• That works fine!
• Also created my local test code and ran it: Also works fine!

So, without even looking any further that tells me there's a problem with your code and perhaps how the the libraries are located or how paths are accessed. I haven't looked into your code at this point to see what you're doing but clearly if my code can load the library so should yours, since your code fails during load which is working in the code I'm running in the same exact environment that your code fails.

I'm going to look at your code and what's different next...

Hello Rick,

So I had a quick look at your sample. First off I can duplicate what you see with the error message when I run your application both as an EXE and from within FoxPro's IDE. In both cases this fails.

Thank you for your test.
The strange thing is that it runs with the same source code with the old DDLs and not with the new DLLs. The libraries are loaded exactly the same and the paths - at least in my source code and also the ww PRGs - are also set the same. So for both the old and the new DLLs.

Ok, so one of the reasons for our different experience is that I'm using wwSftClient which is a new class has a slightly different interface than the old one. This is a replacement for the original wwSftp class that you're using.

The reason for the new class was to clean up that ancient FTP interface and to make the wwSftpClient and wwFtpClient closely compatible using the same API surface which the old one did not do well.

Seeing what you're doing though, I see that the features that you're using from SetDirectory and Listing files those are two methods that work differently.

Taking a look I think SetDirectory is implemented but not documented at this point.

+++ Rick ---

Ok in your version of wwSftp there's a bug that's causing your error:

FUNCTION FtpConnect(lcServer, lcUsername, lcPassword)
LOCAL loSftpClient, loSftp

THIS.nError = 0

IF EMPTY(lcServer)
   lcServer = this.cFtpServer
ENDIF

IF ISNULLOREMPTY(lcUserName)
   lcUsername = this.cUsername
ENDIF
IF ISNULLOREMPTY(lcPassword)
   lcPassword = this.cPassword
ENDIF


IF ISNULLOREMPTY(lcUserName)
   lcUsername = ""
ENDIF
IF ISNULLOREMPTY(lcPassword)
   lcPassword = ""
ENDIF   

loSftp = this.oSftp

loSftp.Timeout = this.nConnectTimeout

*** Messing with this buffer causes file corruption
loSftp.BufferSize = this.nFtpWorkBuffersize

loSftp.ProxyName = this.cHttpProxyName
loSftp.ProxyUsername = this.cHttpProxyUsername
loSftp.ProxyPassword = this.cHttpProxyPassword

IF !ISNULLOREMPTY(this.cPrivateKeyFile)
   loSftp.PrivateKeyFile = this.cPrivateKeyFile
   loSftp.PrivateKeyFilePassword = this.cPrivateKeyFilePassword
ENDIF

*** THIS LINE HERE IS INVALID - wwSftp property no longer exists
* loSftp.wwSftp = this

loSftpClient = loSftp.Connect(lcServer, INT(this.nFtpPort),lcUsername,lcPassword)

IF ISNULL(loSftpClient)
   THIS.cErrorMsg = "Unable to connect to SFTP server: " + this.oSftp.ErrorMessage
   THIS.nError = 1
ENDIF

RETURN THIS.nError
ENDFUNC

AFAIK, the latest version of the Client Tools has that line removed, so the version of wwSftp you're running must be older... – sorry not the case - i was looking in the wrong place. This was not fixed in the release version primarily because it's deprecated, but will be fixed in the next update.

I would recommend moving the code to use wwSftpClient to make sure future changes are reflected. wwSftp is deprecated and won't be updated any more.

IAC, after this fix, now when I run your code I still get errors about invalid connection information, but not the hard Assert failure during FtpConnect().

I'll get a new release out in the next week or so that will have this fixed, but in the meantime you can fix the source code or grab the code from WebConnectionExperimental which has wwSftp with the fix as well as all the updated wwSftpClient wwFtpClient and DLLs.

+++ Rick ---

Hello Rick !

I use now the PROCEDUREs wwDotnetBridge.PRG, wwFtpClient.PRG and wwsftpclient.PRG and the DLL wwDotNetBridge.dll from your last WebConnectionExperimental.zip, change from class wwsFTP to wwsFTPClient and change the following functions and properties:

• nFTPPort => nPort
• FtpConnect => Connect
• FtpSetDirectory => deleted without replacement
• FTPSendFileEx => UploadFile
• FTPClose => Close

The application finally runs with the current PRGs and DLLs.

Thank you for your tireless help 😃

I wish you a happy new year

Glad you got it to work... FINALLY! 😄

FWIW, sftp.FtpSetDirectory is wwSftpClient.ChangeDirectory...

The function names more close match the native commands and are the same for wwFtpClient and wwSftpClient.

That said I recommend not using ChangeDirectory and instead using the appropriate site relative paths for any files or directory lists.

+++ Rick ---