Describe the bug

Reproduced with almost blank app Template. Which was setup as Unpackaged Self-Contained app.

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <RootNamespace>TestApp1</RootNamespace>
    <ApplicationManifest>app.manifest</ApplicationManifest>
    <Platforms>x86;x64;ARM64</Platforms>
    <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>
    <PublishProfile>win-$(Platform).pubxml</PublishProfile>
    <UseWinUI>true</UseWinUI>
    <WinUISDKReferences>false</WinUISDKReferences>
    <EnableMsixTooling>true</EnableMsixTooling>
    <Nullable>enable</Nullable>
+    <WindowsPackageType>None</WindowsPackageType>
+    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
</PropertyGroup>

Referenced packages

<ItemGroup>
    <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.26100.7705" />
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.8.260209005" />
</ItemGroup>

PublishProfile for Single-File deployment

<PropertyGroup>
    <PublishProtocol>FileSystem</PublishProtocol>
    <Platform>x64</Platform>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishDir>bin\publish\</PublishDir>
    <SelfContained>true</SelfContained>
    <Configuration>Release</Configuration>
    <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
    <PublishReadyToRun>false</PublishReadyToRun>
    <PublishSingleFile>true</PublishSingleFile>
    <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

To debug the App I've changed OnLaunched method in App.xaml.cs in the following way.

protected override void OnLaunched(Microsoft.UI.Xaml.LaunchActivatedEventArgs args)
{
+    try
+    {
        _window = new MainWindow();
        _window.Activate();
+    }
+    catch (Exception ex)
+    {
+        File.WriteAllText(Path.Combine(Environment.CurrentDirectory, "test.log"), ex.ToString());
+        throw;
+    }
}

If I rename the executable then I get the following output to the test.log.

Microsoft.UI.Xaml.Markup.XamlParseException: XAML parsing failed.
   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|38_0(Int32)
   at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32)
   at ABI.Microsoft.UI.Xaml.IApplicationStaticsMethods.LoadComponent(IObjectReference, Object, Uri, ComponentResourceLocation)
   at Microsoft.UI.Xaml.Application.LoadComponent(Object, Uri, ComponentResourceLocation)
   at TestApp1.MainWindow.InitializeComponent()
   at TestApp1.MainWindow..ctor()
   at TestApp1.App.OnLaunched(LaunchActivatedEventArgs)

Steps to reproduce the bug

1. Create blank WinUI 3 app
2. Set it as Unpackaged Self-Contained as shown above
3. Publish it as Single-File deployment
4. Rename the published executable in any way like from TestApp1.exe to TestApp11.exe
5. Run the published executable

The App will crash.

Expected behavior

The appliction runs and main window pops into the screen.

Screenshots

No response

NuGet package version

Windows App SDK 1.8.5: 1.8.260209005

Packaging type

Unpackaged

Windows version

Windows 11 version 24H2 (26100, June 2025 Update)

IDE

Visual Studio 2026

Additional context

This bug is follow-up of #5969

I guess that if I rename the executable of the single-file app, it breaks the ms-appx:// links resolution into absolute path.

This scenario is critical because if you download for instance the SomeAppInstaller.exe which was made with WinAppSDK 1.8+, browser will rename the file itself if the file with the same name already exists in the Downloads folder. Then the downloaded executable will be like SomeAppInstaller(1).exe and won't run.

The described problem doesn't reproduces with WindowsAppSDK 1.7 and earlier versions.

There's no known to me workaround.