ExecutablePath in Session construction

Just a quick question.

I am maintaining a legacy app that uses the WinSCP dll library.

It seems to use this constructor to create a session:
According to the docs, ExecutablePath is null by default and will look in its own directory.

What is the effect of adding that parameter? ExecutablePath = "WinSCP.exe"? Is it the same as null or is there some other effect? Will it look in the global path for WinSCP?

I'm just trying to understand why the original author would construct as so.

The app is using WinSCPnet.DLL 5.15.3.0

Imo, this will look for WinSCP.exe in the current working directory. What might be the same as the folder, where the assembly is in. But it might not.

Thanks.

The reason I'm asking is that the program that uses this dll runs into an error where it says there is a dll mismatch.

We don't mess with CWD, so wondering how this is possible.

Is there any foolproof way to fix this so it's always using the dll and exe that is packaged with via NuGet?

Does it fail with ExecutablePath = "WinSCP.exe" or without it?
Post debug log file (Session.DebugLogPath).

The failure is intermittent.

When it fails, it doesn't produce a log.

I get an exception:

Error: WinSCP.SessionLocalException: The version of WinSCP.exe () does not match version of this assembly d:\...\WinSCPNet.DLL at WinSCP.ExeSessionProcess.CheckVersion(String exePath, FileVersionInfo assemblyVersion).

This will happen once every 20 times or so, it's intermittent. I have verified that the exe and the dll match versions.

I tried setting an absolute path in ExecutablePath to d:\...\WinSCP.exe. It produces the same error.

I'm at a loss as I know the versions of the exe and dll match but for some reason, it fails to launch every few runs.

How does the app use the assembly? Does it open one (or few) sessions per run? Or is it opening new sessions repeatedly/continuously? When it fails, does it fail for all sessions within the app run? Or randomly?
Please upgrade to the latest version of WinSCP and post debug logs or both a successful and fails session.

Also, this might be related to your problem:
Issue 2075 – Prevent occasional exhaustion of resources while testing WinSCP executable version on repeated use of .NET assembly