Severity: Info

File: src/Servy.Core/Config/AppConfig.cs lines 84, 89, 104

Finding

public static readonly string ServyDesktopAppReleaseFolder = Path.Combine(
    AppDomain.CurrentDomain.BaseDirectory,
    @"..\..\..\..\..\Servy\bin\Release\net10.0-windows\win-x64\");

public static readonly string ServyServiceManagerDebugFolder = Path.Combine(
    AppDomain.CurrentDomain.BaseDirectory,
    @"..\..\..\..\..\Servy.Manager\bin\Debug\net10.0-windows\win-x64\");

public static readonly string ServyManagerReleaseFolder = Path.Combine(
    AppDomain.CurrentDomain.BaseDirectory,
    @"..\..\..\..\..\Servy.Manager\bin\Release\net10.0-windows\win-x64\");

The TFM segment net10.0-windows is hardcoded into three relative dev-path constants. When the project's <TargetFramework> is bumped (e.g. .NET 11, net11.0-windows), these constants will silently point to a non-existent build output folder — there is no compiler or test that catches the mismatch, only the dev experience for the desktop / manager dev launches will silently stop locating the sibling project's bin folder.

The same TFM is also encoded in setup/publish-fd.ps1, setup/publish-sc.ps1, and the per-project publish.ps1 scripts, so a TFM bump is already a multi-file find-and-replace. Adding three hidden code constants to that list increases the chance of silent drift.

Suggested fix

Either:

1. Compute the TFM at runtime so it follows the assembly:

private static readonly string TargetFramework =
    typeof(AppConfig).Assembly
        .GetCustomAttribute<TargetFrameworkAttribute>()
        ?.FrameworkName ?? "net10.0-windows";

public static readonly string ServyDesktopAppReleaseFolder = Path.Combine(
    AppDomain.CurrentDomain.BaseDirectory,
    @"..\..\..\..\..\Servy\bin\Release\", TargetFramework, "win-x64\\");

2. Or extract a single TargetFrameworkVersion const at the top of AppConfig and reuse it in all three lines, so a TFM bump is a one-line change. The single source of truth makes the dependency obvious.