It's a WinForms application. However, it is indeed somewhat user-unfriendly to distribute (untrimmable) WinForms applications in a self-contained form.
It's usually much better to build them as runtime-dependent but single-file binaries.
E.g. 'dotnet publish -p:PublishSingleFile=true --no-self-contained'* produces a 5.9 MB binary (but obviously needs a .NET desktop runtime installed, it helpfully offers to do so on launch if it's missing).
I assume modifying the solution to use https://github.com/kant2002/WinFormsComInterop + NativeAOT would result in ~30-40MB binary (maybe smaller now? I haven't tested it in a while) as it packages a GUI framework. It could also help with just self-contained and getting trimming to work.
There is a bit of learning curve to all sorts of ways you can build an application with .NET but that's what you pay for having flexible choices over more limited options with Java or Go.
* also retargeted to .NET 9, there is no reason to use out-of-support targets or even sticking to LTS for a distributed application in this case.
It's usually much better to build them as runtime-dependent but single-file binaries.
E.g. 'dotnet publish -p:PublishSingleFile=true --no-self-contained'* produces a 5.9 MB binary (but obviously needs a .NET desktop runtime installed, it helpfully offers to do so on launch if it's missing).
I assume modifying the solution to use https://github.com/kant2002/WinFormsComInterop + NativeAOT would result in ~30-40MB binary (maybe smaller now? I haven't tested it in a while) as it packages a GUI framework. It could also help with just self-contained and getting trimming to work.
There is a bit of learning curve to all sorts of ways you can build an application with .NET but that's what you pay for having flexible choices over more limited options with Java or Go.
* also retargeted to .NET 9, there is no reason to use out-of-support targets or even sticking to LTS for a distributed application in this case.