[Bug 37751] New: WiX Toolset v3.9 installer doesn't open with Wine-Mono (metahostpolicy_GetRequestedRuntime returns CLR_E_SHIM_RUNTIME))
https://bugs.winehq.org/show_bug.cgi?id=37751 Bug ID: 37751 Summary: WiX Toolset v3.9 installer doesn't open with Wine-Mono (metahostpolicy_GetRequestedRuntime returns CLR_E_SHIM_RUNTIME)) Product: Wine Version: 1.7.33 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- The installer stops with the message "Microsoft .NET Framework required for WiX Toolset v3.9.1006.0 setup", even though Wine Gecko is installed. I've traced the problem in this version of WiX Toolset to http://source.winehq.org/git/wine.git/blob/6f98de084b5fa50e08c82ac9bee579e55... $ sha1sum wix39.exe 2906e1e5084053de0819257ad9cefc0673ab8b34 wix39.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com, | |madewokherd(a)gmail.com, | |swdevelop1981(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #1 from Alex Henrie <alexhenrie24(a)gmail.com> --- Created attachment 50264 --> https://bugs.winehq.org/attachment.cgi?id=50264 screenshot -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #2 from Alex Henrie <alexhenrie24(a)gmail.com> --- Created attachment 50265 --> https://bugs.winehq.org/attachment.cgi?id=50265 install log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #3 from Alex Henrie <alexhenrie24(a)gmail.com> --- Created attachment 50266 --> https://bugs.winehq.org/attachment.cgi?id=50266 mscoree trace -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|WiX Toolset v3.9 installer |WiX Toolset v3.9 installer |doesn't open with Wine-Mono |doesn't open with Wine-Mono |(metahostpolicy_GetRequeste |(metahostpolicy_GetRequeste |dRuntime returns |dRuntime returns |CLR_E_SHIM_RUNTIME)) |CLR_E_SHIM_RUNTIME) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #4 from Alex Henrie <alexhenrie24(a)gmail.com> --- Sorry, I meant to say that the error occurs even though Wine Mono is installed. (Wine Gecko is, incidentally, installed too.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, Installer, source URL| |https://wix.codeplex.com/re | |leases/view/136891 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://wix.codeplex.com/re |https://github.com/wixtools |leases/view/136891 |et/wix3/releases/download/w | |ix3111rtm/wix311.exe --- Comment #5 from Vincent Povirk <madewokherd(a)gmail.com> --- Updating download link. 002a:fixme:mscoree:metahostpolicy_GetRequestedRuntime ignoring config file stream It seems this passes a config file stream to metahostpolicy_GetRequestedRuntime, which we don't currently support. That stream specifies a runtime version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #6 from Vincent Povirk <madewokherd(a)gmail.com> --- Patch sent: https://www.winehq.org/pipermail/wine-devel/2019-February/140085.html With this patch, it fails with a file not found exception, trying to load an assembly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #7 from Vincent Povirk <madewokherd(a)gmail.com> --- [0000002B: 0.00000 0] ENTER: System.Reflection.Assembly:LoadFrom (string,System.Security.Policy.Evidence)([STRING:010AC720:BootstrapperCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad], 00000000, ) LoadFrom expects a path or filename according to MSDN, but we get an assembly name. Not sure if this function has some undocumented behavior, or if there's an earlier failure causing it to attempt this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #8 from Vincent Povirk <madewokherd(a)gmail.com> --- This may actually be a COM wrapper error. The program is using System._AppDomain, which may still have an incorrect vtable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #9 from Vincent Povirk <madewokherd(a)gmail.com> --- Yep, the COM wrapper is still wrong, but it's easily fixable now. With that fixed, I get: [0000002B: 0.00068 1] ENTER: (wrapper cominterop) System._AppDomain:CreateInstance (intptr,string,string,System.Runtime.Remoting.ObjectHandle&)(027964C0, [STRING:010AC720:BootstrapperCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad], [STRING:010AC7D8:Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplicationFactory], [BYREF:0032F6D8], ) [0000002B:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load the file 'BootstrapperCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad'. This makes a lot more sense. Not sure why BootstrapperCore isn't found. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #10 from Vincent Povirk <madewokherd(a)gmail.com> --- I think it's supposed to be searching the .exe directory, but since this isn't a managed executable, Mono may not know to do that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #11 from Vincent Povirk <madewokherd(a)gmail.com> --- All of my testing shows that Mono searches the .exe directory, when loading an assembly referenced by another assembly. This is a slightly different case: Mono is loading an assembly by name. From poking around the code, I'm guessing we'd need mono_install_refonly_preload_hook to change Mono's behavior in this case. I really need tests for this, and tests need the _AppDomain COM interface working correctly. I'll have to put this on hold until that's fixed in a wine-mono release. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #12 from Vincent Povirk <madewokherd(a)gmail.com> --- OK, turns out the dll we need is in the module search path, not the exe directory. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #13 from Vincent Povirk <madewokherd(a)gmail.com> --- I'm wrong again. The only place I see the library's path in logs is Mono: Config attempting to parse: 'C:\windows\Temp\{CE63C0A7-F186-42D6-AB03-6524056A10F2}\.ba\BootstrapperCore.config'. It seems this config file is set using IAppDomainSetup.set_ConfigurationFile. The application also calls set_ApplicationBase, maybe the path is set there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #14 from Vincent Povirk <madewokherd(a)gmail.com> --- It has an application base set. Mono has code to search this directory, and it's being called before our hook: Mono: Config attempting to parse: 'C:\windows\Microsoft.NET\Framework\v4.0.30319\\CONFIG\machine.config'. Mono: Domain mscorlib.dll search path is: Mono: path[0] = 'C:\windows\temp\{14CEF1F0-C554-4324-B398-D0E748F47C7A}\.cr\' Mono: End of domain mscorlib.dll search path. 002d:trace:mscoree:mono_assembly_preload_hook_fn "BootstrapperCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad" But the hook is searching .cr when it needs to be searching .ba, because it was called in the wrong domain. That suggests corruntimehostex_CreateDomainEx isn't actually returning an interface to the domain it creates? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #15 from Vincent Povirk <madewokherd(a)gmail.com> --- We're returning the correct _AppDomain interface, which calls methods on the correct AppDomain object, but AppDomain.Current is the root domain during that call. The COM wrapper should presumably switch the AppDomain, or call a remoting wrapper. It seems like this doesn't happen. I tried inserting a remoting-invoke-with-check wrapper in the cominterop wrapper, but that didn't change anything. I think fixing this is beyond me for now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jon.dufresne(a)gmail.com --- Comment #16 from Vincent Povirk <madewokherd(a)gmail.com> --- *** Bug 46613 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #17 from Vincent Povirk <madewokherd(a)gmail.com> --- Also affects Garmin Express installer: https://www.garmin.com/en-US/software/express/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #18 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to Vincent Povirk from comment #15)
We're returning the correct _AppDomain interface, which calls methods on the correct AppDomain object, but AppDomain.Current is the root domain during that call. The COM wrapper should presumably switch the AppDomain, or call a remoting wrapper.
It seems like this doesn't happen. I tried inserting a remoting-invoke-with-check wrapper in the cominterop wrapper, but that didn't change anything. I think fixing this is beyond me for now.
This bit is implemented now, https://github.com/mono/mono/commit/d74e863de3a2a25e20661bfe855b739aca6d868b . It's available in wine-mono 4.9.4. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|mscoree |msxml3 --- Comment #19 from Esme Povirk <madewokherd(a)gmail.com> --- Now the installer crashes after opening and reading an XML file. With 'winetricks msxml3' it gets further and is able to complete the install, though there are some rendering errors with its WPF window. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED URL|https://github.com/wixtools |https://web.archive.org/web |et/wix3/releases/download/w |/20200227003934/https://git |ix3111rtm/wix311.exe |hub.com/wixtoolset/wix3/rel | |eases/download/wix3111rtm/w | |ix311.exe CC| |focht(a)gmx.net Resolution|--- |FIXED Fixed by SHA1| |b06d272d635d30f570b440da230 | |8b53fcc43c7e9 Component|msxml3 |mscoree --- Comment #20 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, --- quote --- This bit is implemented now, https://github.com/mono/mono/commit/d74e863de3a2a25e20661bfe855b739aca6d868b . It's available in wine-mono 4.9.4. --- quote --- resolving fixed then. Wine-Mono integration commit: https://source.winehq.org/git/wine.git/commitdiff/b06d272d635d30f570b440da23... ("mscoree: Update Wine Mono to 4.9.4."). Part of Wine 4.20 release. Thanks Nikolay, Esme. --- quote --- Now the installer crashes after opening and reading an XML file. With 'winetricks msxml3' it gets further and is able to complete the install, though there are some rendering errors with its WPF window. --- quote --- I've created continuation bug 50603 ("WiX Toolset v3.9 installer crashes when loading update feed XML") to avoid the bug being recycled for different problems. $ sha1sum wix311.exe 3f619089b46df893f55e58832ce442678fb0635f wix311.exe $ du -sh wix311.exe 27M wix311.exe Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #21 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.2. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37751 --- Comment #22 from Esme Povirk <madewokherd(a)gmail.com> --- *** Bug 46613 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla