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.

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).

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,

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

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.

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,

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

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.

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

Anonymous wrote:

But the versions of each match

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

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

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

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

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

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).

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.

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 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?

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

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.

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.

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.

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