Closed Sainan closed 4 months ago
.NET Framework.
Doesn't .NET usually get redistributed/is already installed? I guess you wanted the EXE to be self-contained? That's a bit rough, tho.
Publishing as self-contained appears to be the only way for dotnet to generate a single .exe file, otherwise it also requires a .dll next to it. This would be fine if you're installing via the installer, but makes the "standalone" option less...standalone.
https://learn.microsoft.com/en-us/dotnet/core/deploying/
Well, I just tried it again and I was looking at the wrong thing, apparently. With --self-contained false
the .exe under publish/
is only about 15MB. However I'm not sure this will work without .NET 6 installed. Currently setting up a 15H2 VM to test it out.
Yep, it does not work:
It might be a fair assumption to make that a user does have .NET installed, tho. At least I have some .NET 4.5 apps that "just work" and they're <100KB.
.NET Framework 4.x is a completely different beast to .NET 5.x and above.
In a good way or in a bad way? Because from a developer POV, it seemed like a significant downgrade in terms of development experience, hence sticking with the much more usable .NET 4 series.
.NET Framework was/is installed on Windows by default: https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies
This is not the case starting with .NET 5. You must either install it yourself or have it bundled with the application.
Yet another reason to use the .NET 4 series? I admit, I'm not sure how feasable a "downgrade" would be, but might be worthwhile. 154MB is really chunky for an executable, especially one that has to be downloaded.
For reference, Google Chrome's chrome.dll is 211MB.
We see no reason to go backwards and won't be entertaining such a request.
Just because the version number is lower, doesn't mean you'd be going backwards.
That's kind of how version numbers work though...
For one thing, we'd lose out on a bunch of newer language features and various other things. You can see all the changes from the upgrade to .NET 6 here: https://github.com/qmk/qmk_toolbox/pull/421
Also of note is that the Toolbox still uses Winforms, and that appears to be what's taking up a good amount of the filesize. Switching to probably anything else might help here, but I haven't had time to look into it.
With Microsoft, that is how version numbers work. No one using Windows 11 would decline an upgrade to Windows 10. No one writing C++ would purposefully use newer versions of Visual Studio lest they want "surprise crashes" for certain users. And I personally would not accept a downgrade from .NET 4 to .NET 5.
You're more than welcome to fork toolbox and maintain your own. This discussion has completed. Locking.
I thought it might be the resources, but those add up to only like 7MB.