Hi all - I understand win64 support for dotnet is not fully baked, but seems like it's close enough to working (or has worked at some points) that I hope you can help with this issue.
After installing dotnet461 on a win64 prefix, it seems mscoree.dll cannot be found when attempting to load 64-bit executables.
For example, when I start a dead-simple, example dotnet app as follows:
$ wine64 winform64.exe
Eventually you get the following:
0009:err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"winform64.exe" cannot be loaded
0009:err:module:attach_dlls Importing dlls for L"Z:\\winform64.exe" failed, status c0000135
Is it possible the dotnet461 winetricks verb is actually installing 32 bit DLLs into syswow64 location? I ask because when running the following:
$ file ./target/wine-prefix/drive_c/windows/syswow64/mscoree.dll
./target/wine-prefix/drive_c/windows/syswow64/mscoree.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
The 80386 architecture there seems suspicious (however I guess it could be an 'any CPU' DLL). Not sure here; just a guess.
Any thoughts on dotnet461 support on 64 bit wine prefix (on Mac OS X)?
That's expected. 32-bit dlls go in syswow64, 64-bit binaries in system32 (thank Microsoft for that one).
I have no immediate thoughts. I don't know of any easy fixes, but I'm happy to review PRs. AIUI this will need fixes in wine (msi) to be feasible.
Interesting. So if I don't see a mscoree.dll in system32 after dotnet461 install... Perhaps it is indeed not installing for 64 bit?
Correct.
@austin987 before I dig in over the weekend, curious why you say "AIUI this will need fixes in wine (msi) to be feasible." Any tip you can give me?
@austin987 confirming lots of DLLs are not properly installed in 64 bit mode for the various dotnet installers, starting with dotnet4 (in my case). I did manually unpack some of the .cab/.msi/.msu files and found the appropriate 64 bit versions. Moving them over does get around the DLL loading issues but now some other problems.
Should I go ahead and open a Wine bug, you think?
@apemberton you could, though I suspect it's a dupe of one (or more) of these:
https://bugs.winehq.org/show_bug.cgi?id=30713
https://bugs.winehq.org/show_bug.cgi?id=31741
https://bugs.winehq.org/show_bug.cgi?id=34989
https://bugs.winehq.org/show_bug.cgi?id=37856
note: I have not explicitly verified that list, just an educated guess
@austin987 just updating here, as I haven't made an upstream wine bug, given the possibility of creating a dup. I have gotten the .NET 4.0 installation process to work successfully. Will document later, but requires installing for 32 bit, then forcing manual msiexec installation of 64 bits. More to come...
@austin987 I spent a bit of time researching and hacking around this win64 problem... it does indeed seem it's a known problem in the Wine community - with a tangle of existing bugs all likely pointing at the same thing (see Anastasius's comments around 'DLL fixup' in the Wine bug I opened: https://bugs.winehq.org/show_bug.cgi?id=45063)
I have come up with a scripted workaround for this problem for dotnet40, which I suspect will fix any similar issues with subsequent dotnet4X installers, thought I would share here:
winetricks -q remove_mono winxp
if [ ! -e "./dependencies/dotNetFx40_Full_x86_x64.exe" ]
then
curl https://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe --output ./dependencies/dotNetFx40_Full_x86_x64.exe
fi
wine64 ./dependencies/dotNetFx40_Full_x86_x64.exe /q &
export PID=$!
sleep 20
export DOTNETDIR=`find ./target/wine-prefix/drive_c -maxdepth 1 -regex './target/wine-prefix/drive_c/[a-f0-9]*'`
cp -R $DOTNETDIR ./target/wine-prefix/drive_c/dotnet-install
wait $PID
wine64 reg delete "HKEY_LOCAL_MACHINE\\Software\\Classes\\Installer\\Products\\C28643E881181F13CBC489DC69571E2C" /f
wine64 reg delete "HKEY_LOCAL_MACHINE\\Software\\Classes\\Installer\\Products\\DFC90B5F2B0FFA63D84FD16F6BF37C4B" /f
wine64 'msiexec' '/i' 'c:/dotnet-install/netfx_Core_x64.msi' 'EXTUI=1'
wine64 'msiexec' '/i' 'c:/dotnet-install/netfx_Extended_x64.msi' 'EXTUI=1'
wine64 'msiexec' '/i' 'c:/dotnet-install/RGB9RAST_x64.msi' 'EXTUI=1'
rm -rf ./target/wine-prefix/drive_c/dotnet-install
@apemberton I want to ask if this script have to be executed for both dotnet40 and dotnet461 or just dotnet40 and the other one can be installed via winetricks. I'm trying to get Space Engineers to run and I keep getting this error no matter what I do:
err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"SpaceEngineers.exe" cannot be loaded
err:module:attach_dlls Importing dlls for L"C:\\Program Files (x86)\\Steam\\steamapps\\common\\SpaceEngineers\\Bin64\\SpaceEngineers.exe" failed, status c0000135
@apemberton thx for the script. It works on wine 3.6 but not on 3.16 and mscoree.dll not found is a big problem.
@austin987 wondering if you've ever gotten a .NET 4x app working on Wine 64 bit? On MacOS?
Honestly don't think I've tried. I made some binaries for testing a while back, need to get back to it to merge (will be a few weeks, on holiday):
https://github.com/austin987/winetricks/commit/b90aa6f4dde95d88f096a5c84ca11b3f795483f8
I don't run OSX, so I can't comment there.
BTW @apemberton you should try with wine-5.0-rc*; see https://bugs.winehq.org/show_bug.cgi?id=46981
Update to my last comment in this issue: no longer the issue
It is still an issue to me with dotnet452
@Zemogiter with which wine and dotnetXX version you don't have this issue?
@zilion22 try latest stable wine version and dotnet472
I also don't have problems with dotnet480.
All bugs that had been reported have been closed.
Most helpful comment
@austin987 I spent a bit of time researching and hacking around this win64 problem... it does indeed seem it's a known problem in the Wine community - with a tangle of existing bugs all likely pointing at the same thing (see Anastasius's comments around 'DLL fixup' in the Wine bug I opened: https://bugs.winehq.org/show_bug.cgi?id=45063)
I have come up with a scripted workaround for this problem for dotnet40, which I suspect will fix any similar issues with subsequent dotnet4X installers, thought I would share here: