Re: DisableVersionCheck deprecation
This request has been added to the tracker:
https://winscp.net/tracker/1777
https://winscp.net/tracker/1777
- martin
Post a reply
Topic review
- martin
Re: DisableVersionCheck deprecation
OK, I'll consider this.
- chrislong2
Re: DisableVersionCheck deprecation
I can definitely see why there would be problems with many in using that option and why you having to field such posts would get tiresome.
I also think it can potentially be a useful option when used correctly by people that know what they are doing and test such things. The .EXE is what does all the real work. If the .NET library is a reasonably close version as the EXE, one can often expect that most things (even all things) will still work even with a slightly older library if one verifies with the changelog that no affecting changes were made to the library. As I said, the option does add some flexibility for software developers like me that use WinSCP to be able to easily roll out a fix without having to deal with the complexity of the library unless I absolutely need to. By removing the option, you are taking away that flexibility. But your call of course.
I also think it can potentially be a useful option when used correctly by people that know what they are doing and test such things. The .EXE is what does all the real work. If the .NET library is a reasonably close version as the EXE, one can often expect that most things (even all things) will still work even with a slightly older library if one verifies with the changelog that no affecting changes were made to the library. As I said, the option does add some flexibility for software developers like me that use WinSCP to be able to easily roll out a fix without having to deal with the complexity of the library unless I absolutely need to. By removing the option, you are taking away that flexibility. But your call of course.
- martin
Re: DisableVersionCheck deprecation
Is there a specific reason you are doing this beyond just that generally speaking you shouldn't have mismatched .EXE and COM library?
That's the only reason. Every other problem with the assembly is that people use mismatched version, abusing the
DisableVersionCheck. I should have never introduced the option in the first place.
- chrislong2
DisableVersionCheck deprecation
I noted that in recent changelog notes, you are deprecating the DisableVersionCheck setting in the COM library. Is there a specific reason you are doing this beyond just that generally speaking you shouldn't have mismatched .EXE and COM library? I use that setting because I like the flexibility of being able to instruct one of my users to simply replace the .EXE if needed to fix a problem (after I've verified that the existing .NET library would work with the EXE - and I DO research things like that). If you get rid of that, that removes that flexibility and makes it much more complicated because I'd have to recompile with an updated library and have them unregister old lib and register the new lib. Much more complicated than simply replacing the .EXE.