Closed Deadpikle closed 1 week ago
NOTE: When working on #605, to get things compiling again, I intentionally messed up AppCastItem
use. AppName
and AppVersionInstalled
no longer exist on AppCastItem
, so the UIs had to be fixed. As I didn't want to start this issue's refactor immediately, I intentionally swapped out the vars used to something different and noted it in TODOs to fix later. So, if you build from source before a new preview is available, this will be a bug until that's fixed!
This is working again
Very much considering just removing the new AsmResolverAccessor
in lieu of always using AssemblyDiagnosticsAccessor
by default, which would remove the extra lib from NetSparkle
. It's not a huge loss, and if the default assembly path finding works, then users will probably be OK. Need to test that out in a real app as before, with reflection, we basically just loaded the running DLL, but now that we are trim-safe and don't use reflection here, we need the actual path to the actual DLL.
Notably, I don't know if this will work on macOS when inside a .app file. May need to put this in the release notes and make sure users know about this breaking change.
Can also make a tweak and see if https://stackoverflow.com/questions/4764680/how-to-get-the-location-of-the-dll-currently-executing is trim safe. (System.Reflection.Assembly.GetExecutingAssembly().Location
) Don't know right now. I doubt it. Reflection and trimming don't play nice together.
Decided not to use AsmAssemblyAccessor
. No real benefit to using this compared to AssemblyDiagnosticsAccessor
and removes ~1 MB from the library.
For now, the UI cleanup is done. The UI is still attached to the core lib, but things are significantly smaller now and make use of less of the core NetSparkle
now, so I'm happy with things for the moment.
If we want other libraries to be able to use our user interfaces for their own software update processes that may not use the core of NetSparkleUpdater at all, we should remove the use of NetSparkle from the user interface libraries. The user interfaces can be passed just the information they need.
For example:
IUIFactory
methods take aSparkleUpdater
instance and then do nothing with it. This shouldn't be necessary. If end users want to override things with their ownUIFactory
and pull in things that NetSparkleUpdater has, they would be free to use their own instance(s) of NetSparkle as they please, but our core offering would still work.UpdateAvailableWindowViewModel
takes aSparkleUpdater
instance and only uses it to talk to theReleaseNotesUpdater
. TheReleaseNotesUpdater
only uses theISignatureVerifier
, so we can probably remove the need for sending aSparkleUpdater
instance toReleaseNotesUpdater
entirely by just using the interfaces.ASMResolver
(about 1 MB),NetSparkleUpdater.Chaos.NaCl
(~200 KB), andSystem.Text.Json
(~600 KB -- see #601). So, pulling in about 2 MB (~1.5 MB w/o S.T.Json) more, untrimmed. Not a ton, but not negligible. What can be done about this? (The UI dlls themselves are very small.)AppCastItem
to the UI end of things at all: what would that look like? Is that possible? (AKA the UI hardly knows about NetSparkle at all.)Related: #77