Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

Guest

Re: Simple Fix

Johnfrian wrote:

I have an error with no clear answer.

5 seconds after posting that, I realized I had mistaken the Solutions bin folder for the projects bin folder.
Use /{solutionFolderName}/{projectFolderName}/bin/Debug
Do not use /{solutionFolderName}/bin/Debug
Johnfrian

Re: Simple Fix

wjburke2 wrote:

in Visual Studios you must have a copy on WinSCP.exe and WinSCP.DLL copied to you execution (\bin) directory.

I've added both files of the correct version to the projects /bin and /bin/Debug ("everywhere") and I still get the same error.

I have so many questions.
Why doesn't the NuGet package provide all the functionality when installed? Why is my local WinSCP version interfering with what I though to be an independent version ment to be used somewhere else?
My local WinSCP installation is certainly not part of this project. Should I expect this to fail when pushed to production?

Tl;dr:
I don't understand how any of this is connected, thought the NuGet package was enough and now I have an error with no clear answer.
wjburke2

Simple Fix

If you are developing a program in Visual Studios you must have a copy on WinSCP.exe and WinSCP.DLL copied to you execution (\bin) directory. When the call is made and they are missing it will attempt to use the one in your common library.
Guest

Re: PostPostSession.DisableVersionCheck = true unnecessarily required

glipper wrote:

Hello,

Thank you for your reply,

unfortunately, I can't activate full logs because the process is used in a production context and it's very difficult to reproduce this on a dedicated environment.

I got a look at the source code and it seem's the following command can sometimes return null or empty : "FileVersionInfo.GetVersionInfo(exePath);"

I don't know why.

In a first time, I am going to disable version check, then later i will try to integrate the last version 5.7: "Executable winscp.exe is included in .NET assembly package" --> should resolve my problem... i hope.

Best regards,


That sure sounds like a race condition... You don't think it's possible until you catch one in your logs lol.
Guest

Thanks.
AS said I can't reproduce myself, I certainly used steps 'not natural'. I reported for those who would have same situation eventually.
martin

stilmant wrote:

for some reasons when installing the package for another of the project in the solution. Using the 'Manage NuGet Packages for the solution'
it did created such entry so the WinSCP.exe where not copier in BIN folder.

Thanks for your report. Though I was not able to reproduce this.
Can you include step-by-step instructions for reproducing the issue?
And what version of VS and NuGet are you using?
stilmant

To complete my previous post about my issue.

I installed WinSCP.NET using NuGet Package Manager in a solution with more than one project.

The package created the following entry for the current project
<ItemGroup>
<Content Include="WinSCP.exe">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
for some reasons when installing the package for another of the project in the solution. Using the 'Manage NuGet Packages for the solution'
it did created such entry so the WinSCP.exe where not copier in BIN folder.
<ItemGroup>
<Content Include="WinSCP.exe"/>
</Content>
</ItemGroup>

I didn't succeed to reproduce.
stilmant

Hello,

Just had similar error when compiling one of my first code using WinSCP.NET installed using NuGet.
"The version of C:\Program Files (x86)\WinSCP\winscp.exe (5.9.4.0) does not match version of this assembly C:\Users\mstilmant\Git\test\bin\Debug\WinSCPnet.DLL (5.9.6.0)."

The error is understandable but I'm not expecting the code to use C:\Program Files (x86)\WinSCP\winscp.exe (5.9.4.0) since a winscp.exe (5.9.6.0) should come (and it comes) with the NuGet 'packages'.

I will eventually correct my project references (I guess it is that) but previous users reporting similar error may had such issues installing build software on prod server where installed WinSCP wasn't matching because build program wasn't coming with it's own version of winSCP.
martin

patrickdrd wrote:

In general, everything works fine,
but from time to time I get these errors
(I use it in an app that does many connects and disconnects),
and I think there is something wrong with winscp version retrieval process,
I wouldn't like to update because that would include many changes and
it's a production system

Then we would need a debug log file (Sessiom.DebugLogPath) both for successful and failed session (using the latest version of WinSCP).
patrickdrd

In general, everything works fine,
but from time to time I get these errors
(I use it in an app that does many connects and disconnects),
and I think there is something wrong with winscp version retrieval process,
I wouldn't like to update because that would include many changes and
it's a production system
martin

patrickdrd wrote:

same problem with version 5.7.0,
is there any solution for this?

What "same problem"? First, use the latest version of WinSCP. And mainly, use the same version of WinSCP and WinsCP .NET assembly. Basically only the binaries from the WinSCP-5.9.4-Automation.zip package. Or use a NuGet package.
And follow the instructions:
https://winscp.net/eng/docs/library_install
patrickdrd

same problem with version 5.7.0,
is there any solution for this?
fbcjunior

Same problem

I have the same problem... any solution for this bug?
martin

Anonymous wrote:

But the versions of each match

Please attach a full debug log file showing the problem (using the latest version of WinSCP).

To generate log file, set Session.DebugLogPath. Submit the log with your post as an attachment. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.
Guest

martin wrote:

Gudpony wrote:

Hi Was this bug fixed in any of the recent versions. This same error is happening quite frequently for us. We have version 5.5.4.0

It's not a bug. You are using an incompatible versions of winscp.exe and winscpnet.dll.


But the versions of each match
martin

Gudpony wrote:

Hi Was this bug fixed in any of the recent versions. This same error is happening quite frequently for us. We have version 5.5.4.0

It's not a bug. You are using an incompatible versions of winscp.exe and winscpnet.dll.
Gudpony

Hi Was this bug fixed in any of the recent versions. This same error is happening quite frequently for us. We have version 5.5.4.0

AN example of the exception :
WinSCP.SessionLocalException: The version of D:\.......\winscp.exe () does not match version of this assembly D:\......\WinSCPnet.DLL (5.5.4.0). You can disable this check using Session.DisableVersionCheck (not recommended).
at WinSCP.ExeSessionProcess.CheckVersion(String exePath, FileVersionInfo assemblyVersion)
at WinSCP.ExeSessionProcess..ctor(Session session)
at WinSCP.Session.Open(SessionOptions sessionOptions)
at com.luzern.co40.BLL.util.Ftp.UploadSFtp(String remoteFolder, String localTempFolder)
at com.luzern.co40.BLL.util.Ftp.Upload(String remoteFile, String localFile)

An issreset seems to rectify it every time but this is not ideal for our Production enviornment
glipper

PostPostSession.DisableVersionCheck = true unnecessarily required

Hello,

Thank you for your reply,

unfortunately, I can't activate full logs because the process is used in a production context and it's very difficult to reproduce this on a dedicated environment.

I got a look at the source code and it seem's the following command can sometimes return null or empty : "FileVersionInfo.GetVersionInfo(exePath);"

I don't know why.

In a first time, I am going to disable version check, then later i will try to integrate the last version 5.7: "Executable winscp.exe is included in .NET assembly package" --> should resolve my problem... i hope.

Best regards,
martin

Re: PostSession.DisableVersionCheck = true unnecessarily required

glipper wrote:

For information, this problem occurs randomly (it works a lot of the time...).

Please enable debug and session logging and attach a full log files both for successful session and failed one.

To generate log files, set Session.SessionLogPath and Session.DebugLogPath. Submit the logs with your post as an attachment. If you do not want to post the log publicly, you can mark the attachment as private.
glipper

PostSession.DisableVersionCheck = true unnecessarily required

For information, this problem occurs randomly (it works a lot of the time...).
glipper

Session.DisableVersionCheck = true unnecessarily required

Hi,

I have the same problem:

Message : The version of D:\...\winscp.exe () does not match version of this assembly D:\...\WinSCPnet.DLL (5.5.5.0). You can disable this check using Session.DisableVersionCheck (not recommended).

Is it possible to activate "DisableVersionCheck" and "DebugLogPath" options directly in ini configuration file ?

Best regards,
martin

Re: Session.DisableVersionCheck = true unnecessarily required

The winscp573automation.zip package contains winscp.exe version 5.7.3. I've just checked.

Please double-check that you use winscp.exe from this package.

If that does not help, please attach a full debug log file showing the problem (using the latest version of WinSCP).

To generate log file, set Session.DebugLogPath. Submit the log with your post as an attachment. If you do not want to post the log publicly, you can mark the attachment as private.
vargonian

Session.DisableVersionCheck = true unnecessarily required

I get the error SessionLocalException: The version of ***\winscp.exe () does not match version of this assembly ***\WinSCPnet.dll (5.7.3.0). You can disable this check using Session.DisableVersionCheck (not recommended).


I downloaded both the exe and the dll in the same package, so there should not be a version mismatch.