WindowsAppSDK Failed to get rid of ML libraries in app build (Managed, Unpackaged, SingleFile)

Describe the bug

After upgrading from 1.7 to 1.8 I've encountered significant app distribution increase in size. Digging into Release notes I've got that I need to use separate packages instead of new Metapackage.

My package references looks like this.

<PackageReference Include="Microsoft.WindowsAppSDK.Runtime" Version="1.8.251003001" />
<PackageReference Include="Microsoft.WindowsAppSDK.WinUI" Version="1.8.250906003" />

But in output folder I get everything including ML libs:

onnxruntime.dll 21 MB
DirectML.dll 18 MB
Microsoft.Web.WebView2.Core.dll 800 kB

Which increases app size by ~40 MB in total compared to SDK v1.7. Btw, trimming doesn't help at all. The exact package that installs ML libs is Microsoft.WindowsAppSDK.Runtime.

My app doesn't require neither ML nor WebView. How to install individual packages to make the app lighter? Or at least as it was in 1.7?

There's almost no difference in size between installing complete Microsoft.WindowsAppSDK Metapackage or two packages from xml code above. 1 MB lighter or so. Thus I've concluded that replacing Metapackage with individual packages doesn't works as expected for the simple desktop app.

Steps to reproduce the bug

Create WinUI 3 project with v1.8 SDK
Replace Metapackage with two packages from XML above
Build Managed+Unpackaged

Expected behavior

There's no WebView2 or ML libraries in build output folder.

Screenshots

No response

NuGet package version

1.8.251003001

Packaging type

Unpackaged

Windows version

Windows 11 (26100.6899)

IDE

VS 2022

Additional context

Full .csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.19041.0</TargetPlatformMinVersion>
    <RootNamespace>Installer</RootNamespace>
    <AssemblyName>MyInstallerApp</AssemblyName>
    <ApplicationManifest>app.manifest</ApplicationManifest>
    <Platforms>x64</Platforms>
    <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
    <UseWinUI>true</UseWinUI>
    <EnableMsixTooling>true</EnableMsixTooling>
    <Nullable>enable</Nullable>
    <WindowsPackageType>None</WindowsPackageType>
    <ApplicationIcon>icon.ico</ApplicationIcon>
    <IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>
    <SelfContained>true</SelfContained>
    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
    <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
    <PublishSingleFile>true</PublishSingleFile>
    <TrimmerSingleWarn>false</TrimmerSingleWarn>
    <TrimmerRemoveSymbols>true</TrimmerRemoveSymbols>
    <OptimizationPreference>Size</OptimizationPreference>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>
    <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
    <IsAotCompatible>true</IsAotCompatible>
    <EnableCompressionInSingleFile>true</EnableCompressionInSingleFile>
  </PropertyGroup>

  <ItemGroup>
    <Manifest Include="$(ApplicationManifest)" />
  </ItemGroup>

  <!--
    Defining the "Msix" ProjectCapability here allows the Single-project MSIX Packaging
    Tools extension to be activated for this project even if the Windows App SDK Nuget
    package has not yet been restored.
  -->
  <ItemGroup Condition="'$(DisableMsixProjectCapabilityAddedByProject)'!='true' and '$(EnableMsixTooling)'=='true'">
    <ProjectCapability Include="Msix" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="9.0.8" />
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="9.0.8" />
    <PackageReference Include="Microsoft.Extensions.Http" Version="9.0.8" />
    <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.26100.6901" />
    <PackageReference Include="Microsoft.WindowsAppSDK.Runtime" Version="1.8.251003001" />
    <PackageReference Include="Microsoft.WindowsAppSDK.WinUI" Version="1.8.250906003" />
    <PackageReference Include="Serilog" Version="4.3.0" />
    <PackageReference Include="Serilog.Extensions.Logging" Version="9.0.2" />
    <PackageReference Include="Serilog.Sinks.File" Version="7.0.0" />
  </ItemGroup>

  <ItemGroup>
    <Resource Include="icon.ico">
      <CopyToOutputDirectory>Never</CopyToOutputDirectory>
    </Resource>
  </ItemGroup>

  <ItemGroup>
    <None Update="icon.ico">
      <Pack>True</Pack>
      <PackagePath>\</PackagePath>
    </None>
  </ItemGroup>

  <!--
    Defining the "HasPackageAndPublishMenuAddedByProject" property here allows the Solution
    Explorer "Package and Publish" context menu entry to be enabled for this project even if
    the Windows App SDK Nuget package has not yet been restored.
  -->
  <PropertyGroup Condition="'$(DisableHasPackageAndPublishMenuAddedByProject)'!='true' and '$(EnableMsixTooling)'=='true'">
    <HasPackageAndPublishMenu>true</HasPackageAndPublishMenu>
  </PropertyGroup>

  <!-- Publish Properties -->
  <PropertyGroup>
    <PublishTrimmed Condition="'$(Configuration)' == 'Debug'">False</PublishTrimmed>
    <PublishTrimmed Condition="'$(Configuration)' != 'Debug'">True</PublishTrimmed>
  </PropertyGroup>
</Project>

Workaround

Rollback SDK to 1.7.251014001, delete /bin and /obj folders in the project directory and Rebuild

Nov 01 '25 13:11 aepot

Previously closed the issue because I thought that solution was found but I was wrong. The app size issue starts reproducing from earliest SDK 1.8. Sadly nothing helps.

Nov 01 '25 14:11 aepot

Update: same problem for Native-AOT publishing.

Nov 05 '25 09:11 aepot

Same problem: onnxruntime.dll and DirectML.dll are bloating the package size, even for blank app with <PublishTrimmed>true</PublishTrimmed>.

Nov 05 '25 11:11 ramjke

@aepot looking at your project, you look be to using unpackaged and WinAppSDK self-contained. Can I get you to just try referencing the WinUI component package and remove your reference to the Runtime package. The latter is typically only needed when you want framework package deployment rather than self-contained. When you do this, you should notice those ML DLLs should no longer appear. WebView would still appear similar to before as WinUI does have a dependency on it for WebView controls.

Let me know if you have a scenario where you still need to reference the Runtime package while being unpackaged and WinAppSDK self-contained.

Nov 18 '25 01:11 manodasanW

@manodasanW I can't solve this while trying to launch the app in Debug mode from both VS 2022 and 2026:

<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.26100.7175" />
<PackageReference Include="Microsoft.WindowsAppSDK.WinUI" Version="1.8.251105000" />

app.manifest

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="1.0.0.0" name="Installer.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
	<security>
	  <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
	    <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
	  </requestedPrivileges>
	</security>
  </trustInfo>
  
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- The ID below informs the system that this application is compatible with OS features first introduced in Windows 10. 
      It is necessary to support features in unpackaged applications, for example the custom titlebar implementation.
      For more info see https://docs.microsoft.com/windows/apps/windows-app-sdk/use-windows-app-sdk-run-time#declare-os-compatibility-in-your-application-manifest -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>
  
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
    </windowsSettings>
  </application>
</assembly>

If I add Runtime package, then it starts to work but then the bug described in the initial post appears to reproduce.

Update: Event log says that for C:\Users\<user_name>\.nuget\packages\microsoft.windowsappsdk.interactiveexperiences\1.8.251104001\buildTransitive\..\runtimes-framework\win-x64\native\CoreMessagingXP.dll value of the attribute "name" in element "urn:schemas-microsoft-com:asm.v1^file" is invalid.

Trying to figure out, what does it mean. Looks like Microsoft.WindowsAppSDK.InteractiveExperiences package causes building non-runnable app, or something is missing.

Update2: The cause of issue with non-runnable app is:

<PublishSingleFile>true</PublishSingleFile>

If I remove the line, then the app starts building and running fine. But in general the single file build is mandatory for me.

Nov 19 '25 07:11 aepot

I was able to get a repro of the PublishSingleFile issue when component packages are used and got a fix for it. Will look at getting this in for an upcoming 1.8 servicing build.

Nov 26 '25 21:11 manodasanW

@manodasanW thanks for the update, that would resolve the initial bug report.

About ML native libs bound to Runtime package, that doesn't affect me at all but those who want to build framework-dependent apps which requires Runtime package. Probably that may be considered as different issue.

Nov 28 '25 19:11 aepot