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@winehq.org Reporter: alexhenrie24@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
https://bugs.winehq.org/show_bug.cgi?id=37751
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com, | |madewokherd@gmail.com, | |swdevelop1981@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #1 from Alex Henrie alexhenrie24@gmail.com --- Created attachment 50264 --> https://bugs.winehq.org/attachment.cgi?id=50264 screenshot
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #2 from Alex Henrie alexhenrie24@gmail.com --- Created attachment 50265 --> https://bugs.winehq.org/attachment.cgi?id=50265 install log
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #3 from Alex Henrie alexhenrie24@gmail.com --- Created attachment 50266 --> https://bugs.winehq.org/attachment.cgi?id=50266 mscoree trace
https://bugs.winehq.org/show_bug.cgi?id=37751
Alex Henrie alexhenrie24@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)
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #4 from Alex Henrie alexhenrie24@gmail.com --- Sorry, I meant to say that the error occurs even though Wine Mono is installed. (Wine Gecko is, incidentally, installed too.)
https://bugs.winehq.org/show_bug.cgi?id=37751
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, Installer, source URL| |https://wix.codeplex.com/re | |leases/view/136891
https://bugs.winehq.org/show_bug.cgi?id=37751
Vincent Povirk madewokherd@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@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #6 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #7 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #8 from Vincent Povirk madewokherd@gmail.com --- This may actually be a COM wrapper error. The program is using System._AppDomain, which may still have an incorrect vtable.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #9 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #10 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #11 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #12 from Vincent Povirk madewokherd@gmail.com --- OK, turns out the dll we need is in the module search path, not the exe directory.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #13 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #14 from Vincent Povirk madewokherd@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?
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #15 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jon.dufresne@gmail.com
--- Comment #16 from Vincent Povirk madewokherd@gmail.com --- *** Bug 46613 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #17 from Vincent Povirk madewokherd@gmail.com --- Also affects Garmin Express installer: https://www.garmin.com/en-US/software/express/
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #18 from Nikolay Sivov bunglehead@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|mscoree |msxml3
--- Comment #19 from Esme Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=37751
Anastasius Focht focht@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@gmx.net Resolution|--- |FIXED Fixed by SHA1| |b06d272d635d30f570b440da230 | |8b53fcc43c7e9 Component|msxml3 |mscoree
--- Comment #20 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=37751
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.2.
https://bugs.winehq.org/show_bug.cgi?id=37751
--- Comment #22 from Esme Povirk madewokherd@gmail.com --- *** Bug 46613 has been marked as a duplicate of this bug. ***