I installed LO5.0.1.2 x64 on Win7 x64 Home as a administrative install. At first start Win Error message apears "MSVCR120.DLL missing on this computer". The C libraries are normally installed with LO. Did somebody forget to let it be installed in the admin version? See also my question and an answer here: https://ask.libreoffice.org/en/question/57505/lo5-x64-admin-install-missing-mscrv120dll/
I could be wrong, but isn't an application allowed to ship the necessary runtimes with the installer on system like Window$ anyway ? If not, launch the link in browser after the installing user gives the green for it, it's kinda hacky but better than leaving noobs totally clueless.
You find them in the folder "System" in your administrative installation. If your system hasn't got them already, you can copy them manually to the folder of your OS. An administrative installation installs nothing, but only unpacks the download.
(In reply to Regina Henschel from comment #2) > You find them in the folder "System" in your administrative installation. If > your system hasn't got them already, you can copy them manually to the > folder of your OS. An administrative installation installs nothing, but only > unpacks the download. You are correct they are installed in System64 folder. But all my other admin installation have them installed in the Program folder. My question now: Why change the folder? If it is the program folder, Win finds it if it is not installed in a Windows folder.
(In reply to Horst from comment #3) > (In reply to Regina Henschel from comment #2) > > You find them in the folder "System" in your administrative installation. If > > your system hasn't got them already, you can copy them manually to the > > folder of your OS. [...] VI$TA and newer, and any NIX, I'd recommend a symlink instead.
CC'ing David O.
> You are correct they are installed in System64 folder. Interesting, I'm investigating similar failure on Windows 10, but on experimental compiler Visual Studio 2015: [1], [2]. What happens, is, the libraries are installed into C:/System64. I would expect them to be installed into usual location. I had a look into msi msm merge code and saw that we are removing file table styles in this context. I wonder if this may be related? Another option is to install Python 3.5.0 and check, if the CRT is installed in the right location (they are using WiX, we are using NSIS but they also uses the same CRT module). @Stuart, any comment on this? I would also like to kindly ask you to make a smoke test with LO compiled on Visual Studio 2015. I've uploaded the binaries: [1]. [1] https://wiki.documentfoundation.org/Development/msvc-x86_64#Status [2] https://gerrit.libreoffice.org/18560
As on the 64-bit Dev Wiki, this is expected for the 5.0.x builds--actually required--with /A administrative install. Despite OPs suggestion otherwise in comment 3, a default /A administrative installation of a MSI package will *not* register a C++ runtime with the OS. Regina is correct--all the msiexec.exe /A is doing is unpacking the install. Also, our Dev builds do not set the WRITE_REGISTRY value to assert. Not sure a symlink is really appropriate as there will be SxS cache conflicts, believe downloading and installing the runtime for Visual C++ Redistributable for Visual Studio 2013 is always the the correct action if working with /A administrative installs. The Visual Studio 2013 runtime installers are available here: http://www.microsoft.com/en-us/download/details.aspx?id=40784 For work with David Ostrovsky's TB dev builds using VS 2015 you would need the Visual Studio 2015 Visual C++ redistributable runtime(s) correctly installed, those are found here: http://www.microsoft.com/en-us/download/details.aspx?id=48145 @David, *, Grabbed your TB build. As expected a /A administrative install does give the same error without the Visual Studio 2015 Visual C++ redistributable runtimes installed. Once the VC++ 2015 runtime are installed, the /A administrative install of the TB launches without issue. Version: 5.1.0.0.alpha1+ (x64) Build ID: 4a2b1ed4443f7cc2b69f20dfe8c6174b4b79f123 Locale: en-US (en_US) However, as you note, whenever installed--even if CLI for the /i is WRITE_REGISTRY=1 and VCDIST=1, the installer is assigning the runtimes (from GUID {A38EBF59_3A35_3759_B824_C9816882FA56} items) to a System64Folder defined as TARGETDIR\System64. My case on Windows 8.1 Enterprise 64-bit that is D:, even though the log shows the System64Folder = C:\Windows\system32 Do you want the verbose logs? =-ref-= https://wiki.documentfoundation.org/Development/msvc-x86_64#MS_Visual_Studio_C.2B.2B_2013_runtimes http://www.microsoft.com/en-us/download/details.aspx?id=48145 http://www.microsoft.com/en-us/download/details.aspx?id=40784
(In reply to V Stuart Foote from comment #7) > WRITE_REGISTRY=1 and VCDIST=1... Sorry, the msiexec.exe /i CLI switch was really s/VCDIST=1/VC_REDIST=1/ but no joy.
(In reply to V Stuart Foote from comment #8) > (In reply to V Stuart Foote from comment #7) > > > WRITE_REGISTRY=1 and VCDIST=1... > > Sorry, the msiexec.exe /i CLI switch was really > > s/VCDIST=1/VC_REDIST=1/ > > but no joy. Thanks, Stuart. So just to make sure I understand it, we have different behaviour between LO 5.0.1 based on VS 2013 and LO 5.1 (my upload) based on VS 2015: When installed with VC_REDIST=1 and no admin option, LO 5.0.1 (based on VS 2013) would install the runtime correctly into system folder, while LO 5.1 (based on VS 2015) would always install it to TARGETDIR:/System64 ? Ca we compare the verbose log in both cases. What is different? We are using exactly the same code to merge MSM CRT modules into the LO msi. So the only difference would be in MSM CRT module itself. I've seen also this pending issue in MS knowledge base: [1]. * [1] https://connect.microsoft.com/VisualStudio/feedback/details/1746644/microsoft-vc140-crt-x64-msm-merge-module-installs-c-c-runtime-dlls-in-x32-folder
(In reply to DavidO from comment #9) > > When installed with VC_REDIST=1 and no admin option, LO 5.0.1 (based on VS > 2013) would install the runtime correctly into system folder, while LO 5.1 > (based on VS 2015) would always install it to TARGETDIR:/System64 ? > Yes that is correct. > Ca we compare the verbose log in both cases. What is different? We are using > exactly the same code to merge MSM CRT modules into the LO msi. So the only > difference would be in MSM CRT module itself. I've seen also this pending > issue in MS knowledge base: [1]. > > * [1] > https://connect.microsoft.com/VisualStudio/feedback/details/1746644/ > microsoft-vc140-crt-x64-msm-merge-module-installs-c-c-runtime-dlls-in-x32- > folder Looking at the MSI installer packaging directly, as hinted in the ref and a couple of linked KB articles, the VS 2015 packaging for the Visual C++ runtimes are *not* being assigned the 256 bit in the Component table. They are getting a 0. On the VS 2013 packaging they are being set 256. I tried the obvious of setting Attribute of 256 for each in the Component table but that alone does not help. =-ref-= https://msdn.microsoft.com/en-us/library/aa368007%28v=vs.85%29.aspx
(In reply to V Stuart Foote from comment #10) > (In reply to DavidO from comment #9) > > > > When installed with VC_REDIST=1 and no admin option, LO 5.0.1 (based on VS > > 2013) would install the runtime correctly into system folder, while LO 5.1 > > (based on VS 2015) would always install it to TARGETDIR:/System64 ? > > > > Yes that is correct. > > Looking at the MSI installer packaging directly, as hinted in the ref and a > couple of linked KB articles, the VS 2015 packaging for the Visual C++ > runtimes are *not* being assigned the 256 bit in the Component table. They > are getting a 0. > > On the VS 2013 packaging they are being set 256. > > I tried the obvious of setting Attribute of 256 for each in the Component > table but that alone does not help. > > =-ref-= > https://msdn.microsoft.com/en-us/library/aa368007%28v=vs.85%29.aspx Thanks, Stuart. Only two year later, I was able to understand, track down and fix that installer issue. It's trucked here: https://bugs.documentfoundation.org/show_bug.cgi?id=105311