✅ WPF Build size triples after changing target framework to net6.0-windows10.0.17763.0
Hello. My WPF application uses .net6 and recently I was asked to use 'toast' style Windows 10/11 notifications.
Easy enough - I installed
Microsoft.Toolkit.Uwp.Notifications and am using the ToastContentBuilder. However, in order to use the Show() method on the toast it requires changing the Target Framework from .net6.0-windows to net6.0-windows10.0.17763.0. It seemed simple enough but after doing a build I noticed my application size tripled to 34MB. I really would like to get it closer to my previous 11MB.
Digging in I can see why. Simply by changing the Target framework it's now including Microsoft.Windows.SDK.NET.dll in the build which is 23MB in size.
My question here is if there's a way for us to retain notification functionality without needing the large SDK dll? Are there any strategies to avoid this? Possibly by not changing the target framework but still leveraging the toast notification? I have no idea. Really appreciate any help here. Take care!28 Replies
Did you maybe enable self-contained release? That bundles the entire .NET framework with your app
See $singlefile
$singlefile
dotnet publish -c Release -r <runtime identifier> -p:PublishSingleFile=true
Use of -r|--runtime implies --self-contained true. Add --self-contained false to publish as runtime-dependent.
-r RID and -p:PublishSingleFile=true can be moved to .csproj as the following properties:but to target multiple RIDs, you have to use dotnet publish with the -r option for each RID.
You can also add -p:IncludeNativeLibrariesForSelfExtract=true to include native libraries (like Common Language Runtime dlls) in the output executable.
https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file
https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publishCreate a single file for application deployment - .NET
Learn what single file application is and why you should consider using this application deployment model.
.NET Runtime Identifier (RID) catalog
Learn about the Runtime Identifier (RID) and how RIDs are used in .NET.
No it's set to False. I'm already doing a single file, but to see which file was taking 20+MB I disabled that temporarily. So I know it's the
Microsoft.Windows.SDK.NET.dll lib cuz that wasn't previously in my build and it's 23MB
My single file build is 11MB with <TargetFramework>.net6.0-windows</TargetFramework> and if I change the TFW to <TargetFramework>.net6.0-windows10.0.17763.0</TargetFramework> then Microsoft.Windows.SDK.NET.dll is included and the build size increases by 23MB.what about trimming?
Trimming support is disabled in .net6 unfortunately
is this a packaged app?
I recall reading about this a few weeks ago, I don't think you need to use that package, you could just call the COM APIs directly
no nevermind, that still requires you to enable the SDK
Thanks for the response. I'm not sure what you mean about packaged app.
My auto updating logic is centered on it being a single file so each update would contain the sdk, I'm hoping to avoid that
a lot of new Windows 10 APIs require you to have a "package identity" that is granted by MSIX
doesn't apply here though
I see
It seems like I'm just going to have to decide if updates are now 30+mb to include the sdk or dropping toast notifications
Weird how offline web apps can hook into the API so cheaply but a desktop app can't
I suppose the browser is responsible for that though
one thing you could look into is showing a notification Win7-style, with an icon in the notification area
on 7, those notifications will appear as balloons, but on 10 and 11 they appear like any other toast notification
Notifications and the Notification Area - Win32 apps
The notification area is a portion of the taskbar that provides a temporary source for notifications and status.
Have you thought of using UWP?
(instead of WPF)
if small binary size matters that much then UWP is pretty much the go to
I'll try that out!
I haven't. Maybe I should look into it. I was worried about working in a new framework. I think I also determined my use case might not fit. This application needs admin permissions at times and my installer runs several other installers at the same time (exe).
It's an app for connecting to our app infrastructure and requires a few dependencies
sounds like that rules out UWP then
yeah I'm quite certain that you still can do it with UWP but due to how UWP was designed it might be harder
UWP is pretty sandboxed
I think the only hangup really was the installation of uwp app required msix or something like that.
MSIX is fine
And msix doesn't like you installing a bunch of apps that require admin rights. (Rightfully so)
you can ask for full trust
Ah ok. Didn't realize
I will look into the win7 style
Linking this for myself to revisit later when I can get to my laptop https://roundwide.com/implementing-system-tray-app-with-wpf-and-mvvm/
I think this is a good alternative to including the whole Windows SDK just for toast notifications. I lose some functionality - like arguments / responses and setting my own custom image/icons. But shaving 2/3 off the build size seems like a good compromise.
I appreciate all the help here.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity./close
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.
Closed!