I also have the same problem. DOTNET_ROOT is set in my shell, and explicitly clearing it in the launch command fixes the issue.
as an alternative btw, ive moved away from DOTNET_ROOT environment variable and started using DOTNET_INSTALL_DIR instead. microsoft says DOTNET_ROOT is required, but ive yet to have issues. the dotnet install script also checks DOTNET_INSTALL_DIR so it installs to the right place.
its all a workaround for the issue of environment variables transferring to translation layers, be it wine (windows -> linux) or msys (linux -> windows)...
as an alternative btw, ive moved away from
DOTNET_ROOTenvironment variable and started usingDOTNET_INSTALL_DIRinstead. microsoft saysDOTNET_ROOTis required, but ive yet to have issues. the dotnet install script also checksDOTNET_INSTALL_DIRso it installs to the right place.
Unfortunately in my case I believe DOTNET_ROOT is getting set by the Gentoo package.
Either way, really seems like there just needs to be some kind of environment variable hygiene here, although I imagine there are some that need to be passed through...
Unfortunately in my case I believe DOTNET_ROOT is getting set by the Gentoo package.
I'd say that any distro that sets or alters DOTNET_ROOT in its packages instead of using /etc/dotnet/install_location (or just installing to the default location) is terribly misguided and issues should be raised to such distro's package maintainers to fix it.
If I could indirectly get it fixed in Arch Linux, I don't see why other distros have to be stuck with this mistake.
I use OmniSharp Language Server for C# development and DOTNET_ROOT is a requirement for it to work properly:
https://nixos.wiki/wiki/DotNET#.NET_location:_Not_found
There might be another way to fix omnisharp without requiring to set that environment variable
Nothing extracted yet.
Compatibility Report
System Information
log.txt
I confirm:
Symptoms
Log : steam-1086940.log
screenshot : https://imgur.com/DntIXWq
I am a .net developer, and have DOTNET_ROOT set because it installed it in my /home directory by default, which is stupid.
However, when a game uses a .net binary, like Baldurs gate does with its launcher, and
DOTNET_ROOTis set in the host, the DOTNET_ROOT is set in proton, which makes the game's binary crash because it might be looking for something not available in the host (in this case the .net6 desktop runtime).A workaround is to change the launch settings of all games that use a .net binary, but this makes no sense to me as that would be a lot of games that are possibly broken because of 1 environment variable that only makes sense to linux, not wine/proton. personally, i think a protontrick to ignore the environment variable might also do the trick, because completely ignoring it is also questionable
Reproduction
set the
DOTNET_ROOTenvironment variable and start Baldurs gate 3. even things like--skip-launcherwill fail, as it will still run the launcher exe which is unable to load.