3 ms·

Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as: > Writing GUI apps for Windows is

by throwaway2037 2y ago

Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as: > Writing GUI apps for Windows is painful when requirements are unrealistic They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least).

taspeotis 2y ago
.NET since 6 (I think) can be published as a self contained app with the runtime included. It immediately adds some size to the output but you can mitigate it with AOT and trimming.
- AmateurAlert 2y ago
  AOT is currently only available in CLI apps. It's expected for WinUI 3 apps using WASDK v1.6 closer to the end of the year.
  - taspeotis 2y ago
    Oops, I googled it and you’re right.
  - neonsunset 2y ago
    Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible. And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.
    - pjc50 2y ago
      "Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.
      - neonsunset 2y ago
        Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently: "Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files." https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview?tabs=cli#native-libraries https://learn.microsoft.com/en-us/dotnet/core/deploying/sing... For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).
  - MarkSweep 2y ago
    Windows Forms is also making some progress on being fully AOT compatible: https://github.com/dotnet/winforms/issues/4649 https://github.com/dotnet/winforms/issues/4649
ack_complete 2y ago
.NET Framework 3.5 is no longer installed by default starting with Windows 10.
- throwaway2037 2y ago
  The reason why I suggested 3.5 was to include a long line of compatibility with older versions of Windows. And, correct me if wrong, a binary compiled with / targeting 3.5 will still run on 4.8
alkonaut 2y ago
No go for net 4.6 which is installed on every currently supported Windows version back to the original Win10 released almost a decade ago. There are still people running Win 7 but I wouldn't worry about that group having a streamlined experience. With 4.6 they can still install the runtime manually.
- brnt 2y ago
  Why 4.6 and not 4.8? (I assume you mean .Net Framework and not .Net.)
  - scruple 2y ago
    Anyone reading this thread will surely roll their eyes and move on to a different solution. Event the people who recommend this stuff to others get confused about what the fuck is even happening in the .NET ecosystem.
    - alkonaut 2y ago
      It was pretty simple up until the whole netcore fork and netstandard confusion. Then it was confusing for a number of years. And now it's actually pretty simple again. The naming of ".NET" and ".NET Framework" is confusing as hell. But basically Microsoft is hellbent on launching something completely new and having that take over the .NET name, even if it means years of confusion.
  - alkonaut 2y ago
    4.6 instead of 4.8 because 4.6 comes preinstalled with any Windows (Any supported Windows that is, i.e. Win10/11 or equivalent server), so from the user's perspective it will be a no-dependency app, just like a Win32 app.
bux93 2y ago
The requirements are not just unrealistic, but, you know, wrong? > It is extremely hard to stylize native Win32 controls. Yes, it should be! I know Microsoft is errant in its ways itself, but controls should not be custom, they should be standard.

taspeotis 2y ago

.NET since 6 (I think) can be published as a self contained app with the runtime included. It immediately adds some size to the output but you can mitigate it with AOT and trimming.

AmateurAlert 2y ago
AOT is currently only available in CLI apps. It's expected for WinUI 3 apps using WASDK v1.6 closer to the end of the year.
- taspeotis 2y ago
  Oops, I googled it and you’re right.
- neonsunset 2y ago
  Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible. And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.
  - pjc50 2y ago
    "Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.
    - neonsunset 2y ago
      Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently: "Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files." https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview?tabs=cli#native-libraries https://learn.microsoft.com/en-us/dotnet/core/deploying/sing... For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).
- MarkSweep 2y ago
  Windows Forms is also making some progress on being fully AOT compatible: https://github.com/dotnet/winforms/issues/4649 https://github.com/dotnet/winforms/issues/4649

ack_complete 2y ago

.NET Framework 3.5 is no longer installed by default starting with Windows 10.

throwaway2037 2y ago
The reason why I suggested 3.5 was to include a long line of compatibility with older versions of Windows. And, correct me if wrong, a binary compiled with / targeting 3.5 will still run on 4.8

alkonaut 2y ago

No go for net 4.6 which is installed on every currently supported Windows version back to the original Win10 released almost a decade ago. There are still people running Win 7 but I wouldn't worry about that group having a streamlined experience. With 4.6 they can still install the runtime manually.

brnt 2y ago
Why 4.6 and not 4.8? (I assume you mean .Net Framework and not .Net.)
- scruple 2y ago
  Anyone reading this thread will surely roll their eyes and move on to a different solution. Event the people who recommend this stuff to others get confused about what the fuck is even happening in the .NET ecosystem.
  - alkonaut 2y ago
    It was pretty simple up until the whole netcore fork and netstandard confusion. Then it was confusing for a number of years. And now it's actually pretty simple again. The naming of ".NET" and ".NET Framework" is confusing as hell. But basically Microsoft is hellbent on launching something completely new and having that take over the .NET name, even if it means years of confusion.
- alkonaut 2y ago
  4.6 instead of 4.8 because 4.6 comes preinstalled with any Windows (Any supported Windows that is, i.e. Win10/11 or equivalent server), so from the user's perspective it will be a no-dependency app, just like a Win32 app.

bux93 2y ago

The requirements are not just unrealistic, but, you know, wrong? > It is extremely hard to stylize native Win32 controls. Yes, it should be! I know Microsoft is errant in its ways itself, but controls should not be custom, they should be standard.