Add icon to dotnet.exe

[steveharter]

Currently dotnet.exe has a default icon; it should sport a .NET icon. Actual icon TBD (and to include support for different resolutions, etc).

cc @richlander

[steveharter]

See also issue https://github.com/dotnet/core-setup/issues/196 which would add support for a custom icon for each apphost.

[dasMulli]

regarding @jeffschwMSFT's comment from related issue:

The work is underway - right now it is scoped to windows only (both from where it is built and what is being built).

Please don't break cross-targeting/building (not multi-targeting) netcoreapp builds from *nix to windows RIDs.

Quite a few users build .NET Core and even full .NET applications on linux using .NET Core and/or Mono - dotnet/sdk#335
Please don't break scenarios where building .NET Core applications for windows fails using .NET Core build tools on *nix.
Only actually running (and testing) windows-specific .NET Core applications should fail on *nix systems.

[jeffschwMSFT]

@dasMulli we have no intention of breaking that workflow. But it may be the case that building a Windows binary on *nix may not be able to set the icon.
cc @sbomer

[sbomer]

Right, it won't be possible to set the icon or other resources in the apphost when building on unix. They can still be placed in the managed dll (which works today), but trying to build a native apphost targeting windows from unix will not work. The plan is to issue a warning in this case so that devs know what to expect, but the build will still work.

[dasMulli]

But it may be the case that building a Windows binary on *nix may not be able to set the icon.

To me that's still a build break.. As in the resulting binary is not the same as when built from windows.

[dasMulli]

I understand that at least the WPF sdk (hopefully just currently?) requires WinFX targets, but AFAIK, WinForms apps build using the normal SDK / .net core tools at the moment. To me, this indicates that there should be some level of compatibility.
At least AppHost.SetWindowsGraphicalUserInterfaceBit was implemented by adding PE format knowledge to dotnet/sdk. I understand that changing a bit is A LOT easier to implement than current approach but given that there are some PE implementations (roslyn's PEWriter for example, PEReader in coreFx), this would make a good case for extending them to manipulate these kinds of flags and resources.

[jeffschwMSFT]

@dasMulli we are aware of the scenario and have considered implementing in a x-plat friendly way. We were then going to solicit feedback and consider alternatives. Do you have a concrete use that this will break?

[dasMulli]

first, please don't interpret my directness as any form of rudeness, I'm just very direct (German..).
But yes this is a solid first implementation so we'll see. I'm currently trying to port some things to the early alphas. Not being able to use vscode on mac is a bit sad at the moment so using VMs. Also moving more build infrastructure to linux agents would be preferable to maintaining windows agents or nodes/images if possible.

[jeffschwMSFT]

No concern. As you can imagine we have been having implementation debates that weigh a number of factors. Your feedback is invaluable.

[deeprobin]

This was fixed in #70578.