Linux launcher 0.3.22 no longer exports DOTNET_ROOT — client exits silently with a user-installed .NET

Open Beginner friendly
  • Is something wrong?
#198 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, linux, shell
Domain
backend, desktop

Research direction

Start with BuildLinuxLauncherScript in Optimum.Bootstrap.Core/Install/PackageDeployer.cs and compare its generated launcher with the 0.3.18 behavior described in the issue. Check whether the macOS launcher uses the same generation path, as the suggested guard may apply there too. Done means a user-installed SDK in ~/.dotnet is found when the launcher starts, while an existing DOTNET_ROOT is preserved.

Written by the indexing model from the issue text.

Description

Optimum version

0.3.22

Vintage Story version

1.22.7

Platform

Linux x64 — Linux Mint 22.3 (Ubuntu 24.04 base)

Expected behavior

The menu entry or optimum-launch.sh starts the client.

Actual behavior

Clicking the shortcut does nothing at all. Running the same launcher from a terminal prints:

You must install .NET to run this application.

App: /home/<user>/.local/share/optimum/Optimum
Architecture: x64
App host version: 10.0.2
.NET location: Not found

The following locations were searched:
  Application directory:
    /home/<user>/.local/share/optimum/
  Environment variable:
    DOTNET_ROOT_X64 = <not set>
    DOTNET_ROOT = <not set>
  Registered location:
    /etc/dotnet/install_location_x64 = <not set>
  Default location:
    /usr/share/dotnet

From the desktop it is invisible because the .desktop entry uses Terminal=false.

Cause

The 0.3.18 installer wrote a launcher that set DOTNET_ROOT when the SDK lived in ~/.dotnet:

if [[ -z "${DOTNET_ROOT:-}" && -x "$HOME/.dotnet/dotnet" ]]; then
  export DOTNET_ROOT="$HOME/.dotnet"
fi

0.3.22's BuildLinuxLauncherScript (Optimum.Bootstrap.Core/Install/PackageDeployer.cs:365) no longer emits it, and run.sh then execs ./Optimum with no DOTNET_ROOT. The apphost only checks its own directory, DOTNET_ROOT, /etc/dotnet/install_location and /usr/share/dotnet. A user-installed SDK in ~/.dotnet satisfies none of those, so the process exits during apphost bootstrap before any client logging exists.

Suggested fix

Restore the guard at the top of the generated launcher, before exec ./run.sh:

 #!/usr/bin/env bash
 set -euo pipefail
 cd "$(dirname "${BASH_SOURCE[0]}")"
+
+if [[ -z "${DOTNET_ROOT:-}" && -x "$HOME/.dotnet/dotnet" ]]; then
+  export DOTNET_ROOT="$HOME/.dotnet"
+fi

The macOS launcher benefits from the same guard.

Steps to reproduce
  1. Install the .NET 10 SDK into ~/.dotnet only (nothing in /usr/share/dotnet, no /etc/dotnet/install_location).
  2. Install Optimum 0.3.22 on Linux.
  3. Click the menu entry — nothing launches.
  4. DOTNET_ROOT="$HOME/.dotnet" ~/.local/share/optimum/optimum-launch.sh starts the client normally.

Related: #105 (installer dotnet resolution on Windows).

Screenshots

No response

Mods loaded

No response

Checks
  • I confirmed this does not happen on a stock vanilla Vintage Story client.
  • I am running the latest Optimum release.
Dominant language
C#
Stars
22
Forks
4
Avg merge
11m
Merged PRs (30d)
33

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from StratumServer/Optimum

All issues in StratumServer/Optimum

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.