[Bug 55544] New: .NET Desktop Runtime 7 program doesn't work if .NET 7 is installed locally on the system
https://bugs.winehq.org/show_bug.cgi?id=55544
Bug ID: 55544 Summary: .NET Desktop Runtime 7 program doesn't work if .NET 7 is installed locally on the system Product: Wine Version: 8.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: tw0ali@tutanota.com Distribution: ---
Created attachment 75104 --> https://bugs.winehq.org/attachment.cgi?id=75104 I've pasted two logs
I'm on Artix Linux and have installed locally on the system the dotnet-runtime and dotnet-host packages on version 7. I also need to use a Windows program (https://projectpokemon.org/home/files/file/1-pkhex/) that uses .NET Desktop Runtime 7.0.10. I've downloaded the x64 setup from the Microsoft site (https://dotnet.microsoft.com/en-us/download/dotnet/7.0) and installed it in my Wine prefix.
If I start the program I get some errors. I've attached two logs: - the first one happens when both dotnet-runtime and dotnet-host are installed locally, and .NET Desktop Runtime 7.0.10 is installed in the Prefix; - the second ones happens when I uninstall dotnet-runtime and dotnet-host from the system and only .NET Desktop Runtime 7.0.10 is installed in the Prefix.
If I reboot the system and don't install dotnet-runtime and dotnet-host (so only .NET Desktop Runtime 7.0.10 is installed in the Prefix) the program starts fine.
https://bugs.winehq.org/show_bug.cgi?id=55544
Krzysztof Bogacki saancreed@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saancreed@gmail.com
--- Comment #1 from Krzysztof Bogacki saancreed@gmail.com --- This is most likely not a Wine bug but expected behavior resulting from .NET being confused by some stray `DOTNET_ROOT` and `DOTNET_BUNDLE_EXTRACT_BASE_DIR` environment variables. .NET uses the same variables on each system and Wine simply passes them as-is to Windows .NET but because they are Unix paths, they are either completely unrecognized and unusable or they are recognized but the directory doesn't contain a Windows .NET installation so the application just exits.
Try the following, in case of programs published as single file:
`env -u DOTNET_ROOT -u DOTNET_BUNDLE_EXTRACT_BASE_DIR wine64 ./Program.exe`
or the following, in case of traditional multiple-files deployment:
`env -u DOTNET_ROOT -u DOTNET_BUNDLE_EXTRACT_BASE_DIR wine64 dotnet.exe ./Program.dll`
… replacing `Program` with the name of the assembly containing the entry point as appropriate.
(As a side note, it's totally unnecessary to set `DOTNET_ROOT` to `/usr/share/dotnet` because that's the default anyway, unless you need to override another location specified in `/etc/dotnet/install_location`. This might be a bug/oversight in your distribution's .NET packages.)
https://bugs.winehq.org/show_bug.cgi?id=55544
--- Comment #2 from minrosa9 tw0ali@tutanota.com ---
Try the following, in case of programs published as single file:
`env -u DOTNET_ROOT -u DOTNET_BUNDLE_EXTRACT_BASE_DIR wine64 ./Program.exe`
or the following, in case of traditional multiple-files deployment:
`env -u DOTNET_ROOT -u DOTNET_BUNDLE_EXTRACT_BASE_DIR wine64 dotnet.exe ./Program.dll`
… replacing `Program` with the name of the assembly containing the entry point as appropriate.
You were absolutely right. This makes it. Thanks, a lot!
https://bugs.winehq.org/show_bug.cgi?id=55544
Ethan Lee flibitijibibo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |flibitijibibo@gmail.com
--- Comment #3 from Ethan Lee flibitijibibo@gmail.com --- Ran into this with .NET 8 and Wine 9.15, with Fedora's dotnet8 packages installed... Fedora's packages happen to move the runtime root away from the Linux default, so that's probably why DOTNET_ROOT was defined at all!
I would assume that the runtime installers either don't set ever the variable themselves, or it checks to see if it's already set to avoid breaking existing environments.
Either way, it's probably a good idea to filter these out similarly to other cross-platform variables like SDL_VIDEODRIVER to avoid Linux-native settings sneakily getting in the way here.
-
WineHQ Bugzilla