Yes, this is well known - that's why you better declare com-interfaces with the DispId-attribute yourself or you don't update the com-dll without a good reason...

With the current version you code everything on blind, so you don't even know if it works until you debug every line manually, because neither intellisense nor the compiler can help you in any way...

Either way - I am not happy that I have to replace FTP with FTPS in an old VB6-program... but it's working for over 11 years now and the client still wants more.

And using WinSCP it's at least free of charge - so thanks for this great program.

Stefan Kinitz wrote:

but why?

See https://stackoverflow.com/q/2714430/850848

Looking at the source-code my guess is that the ClassInterface-Attribute of the com-classes is strange...

It's currently declared as
but should be declared as

EDIT:
OK ... I found a post back from 2013 that this is meant to be and that I have to recompile the dll myself to get the complete interfaces ... but why?

I can register the dll for COM-use without any errors.

When I try to use "WinSCP scripting interface .NET wrapper" from Visual Basic 6 or VBA, all I get is the classnames without any functions or properties. All I can see is the enumerations and the events of the session-class.

Using newest winscp v5.19.1.11552 and winscp-dll v1.8.3.11552.

Using "OleView.exe/View Typelib..." I can see that all interfaces in the TLB-File are blank (no methods or properties), such as "_Session" (WinSCP.Session) and "_SessionOptions" (WinSCP.SessionOptions).
The only interface containing methods is "ISessionEvents" (WinSCP.ISessionEvents).

Without this info I have to guess funtions, parameters and return values in vb6/vba.
Is this meant to be this way or is this a bug?