TortoiseSVN installer blats over currently installed MSVC redistributable

[Jordan Peck]

Tested with the 1.14.7 64bit msi installer on a fresh Windows 11 install

I have installed the latest MSVC redistributable v14.40.33810.0 from here: https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#latest-microsoft-visual-c-redistributable-version which installs this file "C:\Windows\System32\msvcp140.dll"

After that I install Tortoise SVN, during the install process "C:\Windows\System32\msvcp140.dll" gets replaced with an older version v14.38.33135.0

It seems like the Tortoise SVN installer is not going through the standard process for installing the redistributable since Windows still reports v14.40 as the only installed version:

This older version of the redistributable is causing issues due to this recent change by Microsoft: https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660

To fix the issue caused by the Tortoise SVN installer requires a reinstall of the redistributable.

Ideally the Tortoise SVN installer would install the redistributable via the official installer to avoid blatting over newer versions. The other option is to install msvcp140.dll in the TortoiseSVN bin folder instead of System32 where it affects other apps.

Thanks,

Jordan

[Stefan]

TSVN uses the merge modules to install the c-runtime. That's why you don't see that in the 'installed apps' screen.

https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-170

which means if newer files are really overwritten then that's a bug in those msm files from MS.

However I see that using MSM for distributing the c-runtime is deprecated now, so we might have to change the installer some time in the future. (note that msm are deprecated, but still supported so they must work or MS must fix them).

Also, there can be multiple versions of the c-runtime be installed, and programs will automatically use the correct version.

https://en.wikipedia.org/wiki/Side-by-side_assembly

[Jordan Peck]

Check this stack overflow post, you might have REINSTALLMODE set to overwrite which would force installing over a newer version

https://stackoverflow.com/questions/78655523/visualstudio-2022-crt-mergemodules-overwrites-newer-msvcp140-dll

https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode

[Daniel Sahlberg]

It seems to be set to dmus in r28894, see the following thread in -dev: https://groups.google.com/g/tortoisesvn-dev/c/7GQvMbOxyrw/m/UZPZXKSYAwAJ

Don't know if omus would be better, it should prevent downgrade the thread indicates that there was a problem with some DLLs that were downgraded between 1.13.1 and 1.14.0. Don't know if we can ignore that problem, or if we can say "1.13.1 must go to 1.14.0 before going to [latest]".

/Daniel

[Stefan]

On Tuesday, June 25, 2024 at 5:35:09 PM UTC+2 daniel.l...@gmail.com wrote:

It seems to be set to dmus in r28894, see the following thread in -dev: https://groups.google.com/g/tortoisesvn-dev/c/7GQvMbOxyrw/m/UZPZXKSYAwAJ

Don't know if omus would be better, it should prevent downgrade the thread indicates that there was a problem with some DLLs that were downgraded between 1.13.1 and 1.14.0. Don't know if we can ignore that problem, or if we can say "1.13.1 must go to 1.14.0 before going to [latest]".

I think we will have fewer problems in the future if we go back to "omus" (the default) and just tell users to deinstall TSVN if they have the problem with the old apr dlls. 

[Jordan Peck]

Looking at the docs it looks like the dmus setting will be overwriting newer versions of the runtime, so it would be great if you could set it back to default to avoid that behaviour.

Thanks!