App icon specified in .csproj file doesn't appear on app windows on (at least) Kubuntu Linux and Linux Mint

Describe the bug On Linux (or at least KDE Plasma?), the icon specified in the .csproj file for an Avalonia project (via ApplicationIcon) doesn’t appear on the application’s windows when it is run.

To Reproduce Steps to reproduce the behavior:

1. Add the <ApplicationIcon>ICON_NAME_HERE.ico</ApplicationIcon> element to a PropertyGroup in the .csproj file for an Avalonia project, ensuring that ICON_NAME_HERE refers to the name of an ico file that exists there
2. Build and run the project on Linux (tested on Kubuntu Linux 20.04, and also I think on some version of Linux Mint)
3. Look at the application window’s presence on the Taskbar/Dock/whatever, and in its titlebar (if it has one, and if the current setup is supposed to show windows’ icons in their titlebars)
4. Notice that both are icon’t (or, in less playful terms, notice that the app icon is simply…not present)

Expected behavior The icon should appear in the Taskbar/Dock/etc, and titlebar…some Window Managers/Desktop Environments/etc may not show these elements, but a stock install of Kubuntu 20.04 should, and does so successfully for other apps…just not for this one.

Screenshots On Kubuntu 20.04:

On whatever version of Linux Mint or whatever it is @jmacato uses:

Desktop (please complete the following information):

• OS: Kubuntu, Linux Mint
• Version: 20.04 (Kubuntu), not sure what version of Linux Mint…@jmacato, as it was in his screenshot on Gitter

Additional context https://github.com/mike-ward/Loon is known to be affected by this, as was discovered when I was aiding @mike-ward in documenting how to build this app on Linux earlier today.

Also, it should be noted that I was able to work around the issue by adding

Icon="avares://Loon/app.ico"```
to the opening tag of Loon's `Views/MainWindow.xaml`, though this seemed like more of a dumb workaround than anything, so I figured we'd best bring this up just in case.

[Splitwirez]

On windows it’s most likely embedded into the .exe launcher file. Windows then discovers the icon and uses it for all iconlesswindows.

That’s definitely a thing Windows does, yes…but I’ve just observed a bit of a wrinkle in your explanation: The icon is embedded when building on Linux, as can be determined via software such as Resource Hacker.

Now I’m wondering if Windows may automatically propagate the app executable’s icon to its windows, while I guess Linux doesn’t. If that’s correct, then…this creates a bit of a problem: some Linux users will specify custom icons for their apps via .desktop files.

I don’t know if other Linux apps are able to detect whether or not the user has done this and show the custom icon on their window accordingly…but if it can be done, I’d say Avalonia should do so.

If it were my call, I would say that if the user has specified a custom icon for their program, Avalonia should propagate the icon they’ve provided to any app windows for which no icon is explicitly specified by the app’s developer. If they haven’t, then I suppose the sensible course of action would be to do the same thing, but with the icon embedded into the program itself.

This leads to two other considerations:

1. What if the user has multiple .desktop files for this app? This is entirely possible, and there’s no rule that say the app has to be started from a .desktop file at all…I haven’t a clue if it’s possible to know which one was used to launch the app (if any…)
2. What if the user is using a Desktop Environment that doesn’t use .desktop files, but instead uses something else? (I don’t know of any of these, but apparently they exist…I know nothing else about them)
3. If all of this can be successfully accounted for, I suspect the Avalonia project templates would need to be updated accordingly, so new apps don’t accidentally override all of this. As for existing apps…uh, I guess put out a PSA or something?

[mehmetulukaya]

Maybe this stackoverflow question can help for Windows:

<ApplicationIcon>nome.ico</ApplicationIcon>

` <PropertyGroup>

<OutputType>Exe</OutputType>

<TargetFramework>netcoreapp3.1</TargetFramework>

<ApplicationIcon>nome.ico</ApplicationIcon>

</PropertyGroup>

`