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
- Create blank WinUI 3 app
- Set it as Unpackaged Self-Contained as shown above
- Publish it as Single-File deployment
- Rename the published executable in any way like from
TestApp1.exe to TestApp11.exe
- 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 reproduce with WindowsAppSDK 1.7 and earlier versions.
There's no known to me workaround.
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
PublishProfile for Single-File deployment
To debug the App I've changed
OnLaunchedmethod inApp.xaml.csin 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.Steps to reproduce the bug
TestApp1.exetoTestApp11.exeThe 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.exewhich 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 likeSomeAppInstaller(1).exeand won't run.The described problem doesn't reproduce with WindowsAppSDK 1.7 and earlier versions.
There's no known to me workaround.