Subject says it all. This is not for the faint of heart. Work around: Reinstall the C++ runtime as provided by Microsoft. Here a reinstall of the release "2015" (which was asked for) did not work. Reinstall of releases "2015-2019", which are provided in one file, did work.
I think there are RefCount controls that allow this if LibreOffice package install was the source of the VC++ runtime. And that is it is correct MSI behavior. A subsequent install of LibreOffice should install it again-if needed. Meanwhile MS has moved VC++ support to the consolidated "Windows 10 Universal CRT" multi-release replacing individual VC++ runtimes (2015, 2017, 2019) as "latest supported"[1], and as delivered via MS update mechanisms. @Mike, should/could we start to bundle the Universal CRT for the Windows builds, or would that affect build infra? =-ref-= [1] https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
I see some strange installer problems recently. This one is also mentioned in: https://ask.libreoffice.org/en/question/259118/ But also see tdf#132901, which shows a different installer problem. Given that we didn't change installer logic in the last iteration (6.4 -> 7.0), I have a gut feeling this is related to tdf#130911 and its conversion of Perl scripts to Python...
(In reply to V Stuart Foote from comment #1) > Meanwhile MS has moved VC++ support to the consolidated "Windows 10 > Universal CRT" multi-release replacing individual VC++ runtimes (2015, 2017, > 2019) as "latest supported"[1], and as delivered via MS update mechanisms. > > @Mike, should/could we start to bundle the Universal CRT for the Windows > builds, or would that affect build infra? FTR: this was attempted in v.6.0 (if I recall correctly the version). The package by MS is an .exe that bundles MSUs and *MSIs*, which makes it impossible to install it with our MSI; the only way is to hack it to run outside of the main installation, and require another authentication request, and impossibility to be installed administratively. See also https://developercommunity.visualstudio.com/idea/412198/detect-a-windows-version-from-msi.html , which describes current situation in detail.
(In reply to V Stuart Foote from comment #1) > I think there are RefCount controls that allow this if LibreOffice package > install was the source of the VC++ runtime. And that is it is correct MSI > behavior. A subsequent install of LibreOffice should install it again-if > needed. A reinstall of LO 6.4.5.2 (or 6.4.4) did not fix it in this case.
(In reply to Olaf Langmack from comment #0) > This is not for the faint of heart. People still running Windows 7 need to purchase "extended support" on a yearly basis, which they can do for up to 3 years. They will have serious reasons to do so, and will be very careful with these installations. Why then install an "early adopter" distribution? It was the first time I had any issue with LO, so I had forgotten already the distribution was for early adopters. Thank for your excellent work.
(In reply to V Stuart Foote from comment #1) > I think there are RefCount controls that allow this if LibreOffice package > install was the source of the VC++ runtime. And that is it is correct MSI > behavior. . You must be right (but not about generic "A subsequent install of LibreOffice should install it again-if needed"; it's only true for LO 7.0 or newer). LibreOffice uses MSMs to bundle VCRT. And looks like MS has changed the RT between VS 2017 and VS 2019. Previously it didn't include a file VCRUNTIME140_1.dll for 64-bit VCRT (and that must be the actual file that is missing, not VCRUNTIME140.dll, right?). So likely what happens is this (one possible scenario): VCRT from 2017 is pre-installed on system, having an old VCRUNTIME140.dll, and no VCRUNTIME140_1.dll, in System32; ref count of VCRUNTIME140.dll is non-0. VCRT from 2019 is installed by LO 7.0. This overwrites VCRUNTIME140.dll with a newer version (that *has dependency on VCRUNTIME140_1.dll*), increases ref count of VCRUNTIME140.dll to > 1, and copies VCRUNTIME140_1.dll to System32 with ref count 1. LO 7.0 is deinstalled. This decreases ref counts of both VCRUNTIME140.dll and VCRUNTIME140_1.dll; the latter gets ref count of 0, and gets removed, while the former is still non-0, and is kept (not downgraded!). This breaks the state of VCRT on system, since not all DLLs of the partially installed runtime are on the system (VCRUNTIME140.dll of VS2019 is present, it needs VCRUNTIME140_1.dll, bit the latter is absent). LO 6.4 is installed. It depends on VCRT 2017; it sees that VCRUNTIME140.dll of a newer version is already on system; it doesn't replace it (naturally), and so the broken VCRT is kept on system. === Likely we need to make our installation to make the redist non-uninstallable. That would prevent the step when uninstallation of LO 7.0 broke it.
https://gerrit.libreoffice.org/c/core/+/100426
(In reply to Mike Kaganski from comment #6) > (In reply to V Stuart Foote from comment #1) > between VS 2017 and VS 2019. Previously it didn't include a file > VCRUNTIME140_1.dll for 64-bit VCRT (and that must be the actual file that is > missing, not VCRUNTIME140.dll, right?). Yes, this is correct. At least eventually "VCRUNTIME140_1.dll" was missing, not "VCRUNTIME140.dll" In the beginning a "VCRUNTIME140.dll" was said to be missing, but not in the end, before the workaround fixed the issue. I had been installing/reinstalling a number of releases in order to somehow get back to a working LO install. I messed this up in the bug report. I thought the "_1" may have been due to repeated downloads of MS files. Upon download if a filename already exists, they receive an additional postfix like "(1)". The filename does not say whether a "2015" redistribution is in there, or the "2015-2019". (...) Some magical thinking going on. Sorry.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0872e8cc87d753e6bdda9fad510a6b71cf96565f tdf#135579: Don't uninstall vc_redist: make it permanent It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Let me hope this is the correct fix.
Ref: https://developercommunity.visualstudio.com/content/problem/1143857/msms-for-vcrt-from-vs2019-makes-msi-package-breaki.html
Created attachment 164151 [details] Screenshot LODev 70100 Win x64 "Draw" tries to open an odg-file, but only outer frame of its window shows.
(In reply to Olaf Langmack from comment #12) Is this somehow related to the bug handled here in this issue?
I have installed LO Dev 7.0.1.0.0 Win_x64 2020-08-11_09.10.29 on Windows 7 Professional SP1 with ESU then try to open the odg file with sdraw.exe - only the outer frame of the window shows, see attachment - the window can be closed via the "x"-button at the upper right deinstalled LODev70100 All the while LO 6.4.5.2 remains installed Opening the same odg file works like a charme With the previous install LO 6.4.5.2 would have been removed, and after reinstalling it, the odg file would not open, but rather ask for the infamous VCRUNTIME*
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/989f050f02ee31a771b66e8eaf764e53ad3d8bdc tdf#135579: Don't uninstall vc_redist: make it permanent It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 137004 has been marked as a duplicate of this bug. ***
*** Bug 133596 has been marked as a duplicate of this bug. ***