WinSCPnet.dll 6.3 missingMethodExceptions : RemoteFileInfoCollection.GetEnumerator

We have been using WinSCPnet.dll since long time with RemoteFileInfoCollection.GetEnumerator, but suddenly in latest 6.3 (1.15.0.14793) version this is not available anymore so our application crashes. Is this a known issue? Can you add this back in next version? I want to be able to continue to use the latest version in case there is some future security fix. Our customers download and use latest automation version with AssemblyRedirect without need of recompilations of all other applications.

If there is a breaking change in interface, please keep both the old and the new implementation and recommend to use the new implementation instead of removing existing interface causing breaking change.

WinSCP automation 6.1.2 (1.14.0.13797) still works fine so they change seems to be related to this :
https://github.com/winscp/winscp/commit/6f38e242d99e819b5bb394bd717345e9cf62a065

Here is the missing implementations (picture)

Do I understand right that you are explicitly calling something like this?

Unfortunately I have not been able to find exactly where exception is happening yet, as the code is Jitted in callbacks/new thread start when returning from polling start and crashing before logging, but there is no GetEnumerator direct call found anywhere in my searches, but indirectly via List and Dictionary objects when using foreach calls where information is stored about which files have been downloaded (yet to be deleted), which are pending (not downloaded yet), which already downloaded and deleted (duplicate check).

It is more related to these indirect IEnumerable operations where GetEnumerator is needed:

• https://learn.microsoft.com/en-us/dotnet/api/system.collections.ienumerable.getenumerator
  
• https://james-ramsden.com/implement-ienumerable-c/
  
• https://www.codeproject.com/Articles/474678/A-Beginners-Tutorial-on-Implementing-IEnumerable-I
  

---

I tried to reproduce the issue a lot, but not possible. So I decided to recompile existing code where it fails and when decompiling the old code which is compiled against older version of WinSCP where GetEnumerator existed, it is then optimised and changed to use this instead, so .NET seems to prefer this during compilation (compiler usually try to use the fastest, best performant)
Source:
So best to keep this as all previously compiled code may use GetEnumerator. Many have old code which is hard to recompile so best to keep APIs compatible for quick simple update via AssemblyRedirect. Some may also use this directly if it is more optimised and was available.

Sample AssemblyRedirect used in .NET applications:

Hello Martin,

Seems I found the issue. All previous code compiled with your older versions are optimized automatically to use the GetEnumerator instead. When testing with newly compiled code there is no issue. Problem is that many have older code that is not easily recompilable and our old version will not be possible most likely. So would be great to get this back in there to avoid compatibility issues.

Also since .NET is optimizing for this, it is probably the fastest implementation as well.

Thanks
Niklas

Well, indeed, the implementation of GetEnumerator was previously at each of the collection class exposed by WinSCP .NET assembly API. In the last version that implementation was moved to a common parent class. That indeed breaks binary compatibility. But tbh, we never claimed that we keep binary compatibility. The code level API has not changed.