Current TinderBox 39 Windows builds of master (for the 19th and 20th of September) fail and rollback during installation. Receive below Error 1937 invalid signature when attempting to register a global assembly "cli_cpuhelper_assembly". Full installer error: Product: LibreOfficeDev 4.2.0.0.alpha0 -- Error 1937.An error occurred during the installation of assembly 'cli_cppuhelper,publicKeyToken="ce2cb7e279207b9e", version="1.0.22.0",culture="neutral",processorArchitecture="x86"'. The signature or catalog could not be verified or is not valid. HRESULT: 0x80131045. assembly interface: IAssemblyCacheItem, function: Commit, component: {3097BD78-8BBE-333E-D579-23FA7B15BB34} =-=-= A search of the .MSI with MS Orca shows the faulting Component GUID/CLSID as: gid_file_lib_cli_cppuhelper_assembly__libreofficedev4_ure_bin {3097BD78-8BBE-333E-D579-23FA7B15BB34} LODev_URE_bin_4ff438578 0 MsiNetAssemblySupport >= "4.0.0.0" cli_cppuhelper.dll =-=-= Notes: Installation is run from CLI with WRITE_REGISTRY=1 Multiple downloads, and consistent HASH results for these two TB 39 installers: master~2013-09-19_08.51.58_LibreOfficeDev_4.2.0.0.alpha0_Win_x86.msi master~2013-09-20_07.45.08_LibreOfficeDev_4.2.0.0.alpha0_Win_x86.msi However, if installation is run from CLI with administrative /A, the installation does not error and program runs with out issue following adjustment to bootstrap.ini Unclear if this is the only signature issue, or was just the first to fail and aborts the installation.
Maybe Tinderbox 39 uses .NET 4.5 and you have only 4.0.
I am having problem on a Windows 7 sp1 64-bit Ultimate system where I have previously installed and run the 2013-09-09 TB 39 build with no issue. =-=-= (In reply to comment #1) > Maybe Tinderbox 39 uses .NET 4.5 and you have only 4.0. That doesn't seem to have been the issue. But just to be sure... Loaded .NET 4.5 full version--no improvement. Loaded the Visual C++ 2012 runtimes (32bit and 64bit) to gain access to msvcr110.dll--no improvement. Disabled AV (SCEP 2012)--no improvement. =-=-= Today's 21 Sep build also throws Error 1937 for the cli_cppuhelper assembly signature, extract here from /L*v log: MSI (s) (DC:AC) [12:26:01:341]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=529712370) MSI (s) (DC:AC) [12:26:01:450]: Assembly Error:Strong name signature verification failed for assembly '%1'. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. MSI (s) (DC:AC) [12:26:01:450]: Note: 1: 1937 2: {3097BD78-8BBE-333E-D579-23FA7B15BB34} 3: 0x80131045 4: IAssemblyCacheItem 5: Commit 6: cli_cppuhelper,publicKeyToken="ce2cb7e279207b9e",version="1.0.22.0",culture="neutral",processorArchitecture="x86" DEBUG: Error 2835: The control ErrorIcon was not found on dialog SetupError Internal Error 2835. ErrorIcon, SetupError Error 1937.An error occurred during the installation of assembly 'cli_cppuhelper,publicKeyToken="ce2cb7e279207b9e",version="1.0.22.0",culture="neutral",processorArchitecture="x86"'. The signature or catalog could not be verified or is not valid. HRESULT: 0x80131045. assembly interface: IAssemblyCacheItem, function: Commit, component: {3097BD78-8BBE-333E-D579-23FA7B15BB34} MSI (s) (DC:AC) [12:27:33:240]: Product: LibreOfficeDev 4.2.0.0.alpha0 -- Error 1937.An error occurred during the installation of assembly 'cli_cppuhelper,publicKeyToken="ce2cb7e279207b9e",version="1.0.22.0",culture="neutral",processorArchitecture="x86"'. The signature or catalog could not be verified or is not valid. HRESULT: 0x80131045. assembly interface: IAssemblyCacheItem, function: Commit, component: {3097BD78-8BBE-333E-D579-23FA7B15BB34} Action ended 12:27:33: InstallFinalize. Return value 3. =-=-= Notes: These installations are from command line, with a WRITE_REGISTRY=1 value set. I am able to install builds on Windwos 7 sp1 64-bit Enterprise, with just .NET 4.0 Full, and MSVCR110 for VS C++ 2012 already present. Also able to install on Windows 8 64-bit Enterprise. I was unable to install on Windows XP sp3 Pro 32-bit, same Error 1937 for the cli_cppuhelper signature.
The build from the 16 also threw error 1937. As did today's 22 Sep build. Both of those installations were run without setting a WRITE_REGISTRY=1 flag. I've sent to QA mail list to ask if anyone else is having similar issues.
Created attachment 86323 [details] Last install that completed with no Error 1937 issue A bit further, on affected system--TB 39 builds of Master for 10 Sep and 11 Sep both install without issue. TB 39 build for 15 Sep fails with the Error 1937. Verbose installer logs for the 11th (last good) and 15th (first failure) attached. =-=-= These were last builds to complete installation... Version: 4.2.0.0.alpha0+ Build ID: 1ea33a8cfc5bc51d0cf83989702b8be82cf52c49 TinderBox: Win-x86@39, Branch:master, Time: 2013-09-10_06:19:34 Version: 4.2.0.0.alpha0+ Build ID: 02b0d09ee02ea3ed3b489c2637f87c5e42aea71b TinderBox: Win-x86@39, Branch:master, Time: 2013-09-11_03:52:57
Created attachment 86324 [details] Log of first TB 39 build of master to fail with installation Error 1937
this could be caused by f89cce877cc0480e00ee226780dec887f9d0063a which would cause the installer to put the file instdir/*/URE/bin/cli_cppuhelper.dll into the installation set where previously it probably took the file from solver. there is some weird stuff going on with signing these Cli files during the build, maybe the one in instdir is before the signature is applied and that causes the problem. probably can't investigate a proper solution for this until after Milan but i pushed a quick fix that should hopefully make your QA life easier.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5fa3764c74047cbee4b825195a8f3b94ba15ffd fdo#69601: quick fix for wrong cli_cppuhelper.dll in instset The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Michael, (In reply to comment #6) > probably can't investigate a proper solution for this until after Milan > but i pushed a quick fix that should hopefully make your QA life easier. Thanks, unfortunately the quick fix did not. Version: 4.2.0.0.alpha0+ Build ID: 571f49ffed792095fd41e2d07dbe30befa99a5b8 TinderBox: Win-x86@39, Branch:master, Time: 2013-09-23_02:14:57 on Windows 7 Ultimate sp1, 64-bit. The same signature error for the cli_cppuhelper assembly before install abort and roll back... But can wait til after Milan conference, can work on most QA issues with a /A administrative installation. =-=-= MSI (s) (88:2C) [08:41:13:561]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=552131826) MSI (s) (88:2C) [08:41:13:670]: Assembly Error:Strong name signature verification failed for assembly '%1'. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. MSI (s) (88:2C) [08:41:13:670]: Note: 1: 1937 2: {3097BD78-8BBE-333E-D579-23FA7B15BB34} 3: 0x80131045 4: IAssemblyCacheItem 5: Commit 6: cli_cppuhelper,publicKeyToken="ce2cb7e279207b9e",version="1.0.22.0",culture="neutral",processorArchitecture="x86" DEBUG: Error 2835: The control ErrorIcon was not found on dialog SetupError Internal Error 2835. ErrorIcon, SetupError
Created attachment 86561 [details] MSI verbose install log of sucessful install TB 39 master for 20130925 With today's TB 39 build of master got a clean install. Version: 4.2.0.0.alpha0+ Build ID: c5c4ab6c545acc9caeaa8bc1cef122a0862d1168 TinderBox: Win-x86@39, Branch:master, Time: 2013-09-25_00:06:15 No error when publishing assemblies. MsiPublishAssemblies: Application Context:Global, Assembly Name:cli_cppuhelper,publicKeyToken="ce2cb7e279207b9e",version="1.0.22.0",culture="neutral",processorArchitecture="x86" MSI (s) (70:AC) [09:46:25:387]: Executing op: ActionStart(Name=PublishFeatures,Description=Publishing product features,Template=Feature: [1]) Not sure if that is the final resolution regards handling Signatures, but resolving WFM. Attaching verbose MSI install log for today's build.
Setting resolved works for me now.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=decf809674a837bfddb5b9a376502927364377e8 fdo#69601: refactor CliNativeLibrary The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
should be fixed now