Repository navigation
Cut the Windows install from 541 MB to 212 MB (stop shipping unused VLC builds and symbols) - #211
Conversation
Only reference and enable the LibVLC runtime the target needs (the Windows package copied the x64, x86 and arm64 engines regardless, and the Mac package added libvlc.dylib to every build), and drop SkiaSharp's and HarfBuzzSharp's native .pdb files (100 MB) from the publish. win-x64: 541 -> 212 MB; linux-x64 no longer bundles the Windows/macOS VLC builds (185 MB tarball -> 108 MB uncompressed). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 54 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to This change shrinks the install size by shipping only the LibVLC runtime for the target platform and dropping third-party native symbol files. No concrete merge-blocking risk was found. The author asks for a radio playback smoke test from a built artifact, which is a reasonable follow-up check. Pre-merge checks |
|
Elite Dangerous is an x64-only game and the installer publishes win-x64; on Windows on ARM an x64 process runs emulated and loads the x64 engine. So only the x64 VLC engine is ever wanted: enable it for Windows targets and explicitly disable x86 and arm64 (the package enables them by default). Verified: win-x64 publish still 212 MB with only libvlc/win-x64. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The installed Windows app was 541 MB. About 320 MB of that was packaging waste, not the app.
What was in the install
libvlc/win-x86+libvlc/win-arm64(VLC builds for CPUs the x64 installer never runs on)libSkiaSharp.pdb+libHarfBuzzSharp.pdb(native debug symbols)libvlc.dylib(a macOS library in a Windows install)Causes:
VideoLAN.LibVLC.Windowscopies the x64, x86 and arm64 engines unless told otherwise (its targets file exposesVlcWindowsX86Enabled/VlcWindowsArm64Enabled, which were never set),VideoLAN.LibVLC.Macaddslibvlc.dylibto every build, and SkiaSharp/HarfBuzzSharp ship their native.pdbfiles in the sameruntimes/folder as the DLLs. The csproj comment claimed these were "filtered by target RID at publish time"; they are not. The Linux publish carried the Windows and macOS VLC builds as well, which is why its tarball was 185 MB.Change (
EDNexus.App.csprojonly)RuntimeIdentifier(a plain dev build with no RID uses the machine it is built on): Windows package only forwin-*, Mac package only forosx-*, and only the matching architecture of the Windows engine..pdbfiles (libSkiaSharp,libHarfBuzzSharp) from the publish list. EDNexus's own.pdbfiles stay.Measured (local
dotnet publish -c Release --self-contained)After: only
libvlc/win-x64, no.dylib, no native symbol files. Fulldotnet testgreen. The Windows installer and Flatpak bundle should shrink accordingly in the next release.Safe because
win-x64only, so the x86/arm64 VLC builds were never loaded. On Windows on ARM an x64 process runs under emulation and LibVLCSharp loads the x64 engine; Elite Dangerous itself is x64-only.libvlc, never the bundled Windows/macOS files.Not verified
I could not run the installed app or play audio here (a locally built app auto-installs the latest release). Please smoke-test the radio from a build of this (start a station) before relying on it; the removed files are architectures and symbols the x64 build does not use, so this is expected to be a no-op for playback.
Possible next steps (not in this PR)
PublishTrimmed/ReadyToRun for the .NET part: riskier with Avalonia, separate effort.🤖 Generated with Claude Code
Summary by CodeRabbit