dotnet461 on 64 bit wine prefix

[apemberton]

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)?

[austin987]

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.

[apemberton]

Interesting. So if I don't see a mscoree.dll in system32 after dotnet461 install... Perhaps it is indeed not installing for 64 bit?

[austin987]

Correct.

[apemberton]

@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?

[apemberton]

@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?

[austin987]

@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

[apemberton]

@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...

[apemberton]

@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

[Zemogiter]

@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 

[bergstar]

@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.

[apemberton]

@austin987 wondering if you've ever gotten a .NET 4x app working on Wine 64 bit? On MacOS?

[austin987]

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):
austin987@b90aa6f

I don't run OSX, so I can't comment there.

[austin987]

BTW @apemberton you should try with wine-5.0-rc*; see https://bugs.winehq.org/show_bug.cgi?id=46981

[Zemogiter]

Update to my last comment in this issue: no longer the issue

[zilion22]

It is still an issue to me with dotnet452
@Zemogiter with which wine and dotnetXX version you don't have this issue?

[Zemogiter]

@zilion22 try latest stable wine version and dotnet472

[mirh]

I also don't have problems with dotnet480.
All bugs that had been reported have been closed.

[Enteneller2017]

It seems to be still an issue with recent wine versions:
https://bugs.winehq.org/show_bug.cgi?id=48847

[LECbg]

Hi, I'm running Wineskin on MacOS (MacBook Air M1, 2020). I don't even know how I managed to make Wine work because it it was a nightmare with M1's architecture (I think I finally did it by installing WineBottler). After that, I installed Wineskin and proceeded to wrap my Windows app. I'm using:

• Wrapper: Wineskin 2.9.1.5
• Engine: WS11WineCX64Bit22.0.1

I'm trying to install .Net 4.6.1 and I haven't managed to make mscoree.dll appear anywhere. Using winetricks is also a bit of a pain because I can't use custom commands, so I can't uninstall, nor anything, just "check boxes"... I've tried using this:

But the GUI seems to swallow the text, as winetricks complains about getting no parameters (as far as I understand).

Also, almost always, Wineskin crashes after "running" the custom command.

I would like to try @apemberton's solution, but I don't know how to run winetricks' commands. I'va also tried to run the executable inside the .app, but I get an error:

> ./myapp.app/Wineskin.app/Contents/Resources/winetricks -q remove_mono winxp
------------------------------------------------------
warning: wineserver not found!
------------------------------------------------------

Any help would be really appreciated.

Thank you in advance!

---

Btw, I've managed to run simple apps as notepad, so Wine seems to work properly despite M1's ARM architecture.

Also sorry if this doesn't belong here, but after a lot of googling, this is the first place where I see a possible solution and I can't try it...

[austin987]

@LECbg I'm not sure what's going on there, but it looks like wine isn't installed globally. I don't have a mac, nor an M1, so not sure what to suggest.

FWIW, it's likely with mac that wine is being 'installed' somewhere out of the way, so it's not in the system PATH. Which is why winetricks isn't finding it.

Definitely a different issue than described here. I'd suggest following up with WineSkin.

[fexscruta]

@apemberton @LECbg I had the same issue with dotnet installations and missing mscoree.dll running Wineskin and the WS11WineCX64Bit22.0.1-1 engine. The .exe I wanted to (PAC2021) run simply could not start because of some problem with mscoree.dll. I did a lot of trial and error but in the end found a way to get my app running.

Instead of using the Winetricks UI within Wineskin in order to install dotnet (dotnet48 in my case), I started using the Winehq Engine (in the utilites section within Wineskin Advanced). From there I did the following:

1. Uninstall the mono package using winetricks remove_mono.
2. Install dotnet version 4.8 using winetricks dotnet48. Installation took a while. Winetricks will first install dotnet4, which was somewhat stuck in a loop but I kept waiting and eventually it would finish installing. After that, Winetricks started installation of dotnet48 which also got stuck in a loop, and that time for good! I waited approx. 10 minutes before I decided to first click the cancel button within the .net installter from Microsoft. Since this did not work, I quit the process in the Winehq Engine by using the command cmd+q.

I had lost all my hopes but when running the Wineskin uninstaller, the .net framework 4.8 showed up as installed. I closed Wineskin and double-clicked my App and voilà: it actually worked! No darn "fixup_imports_ilonly mscoree.dll not found" error any more, just a properly running windows app 🥳

So maybe some of you can try this method and see if it works. Hopefully it does!

[austin987]

In newer wine (tested wine-8.3), dotnet461 installs in a 64-bit prefix (at least, on Linux, can't say about Mac).

64-bit dlls are also installed (and running a 64-bit .Net app works).

Not sure when it was fixed, but also works in wine-7.12 (so it's been fixed for a while).