Problem description:
Issue with drawing main form Icon on windows 7, 10 x64.
Actual behavior and Expected behavior:

Minimal repro:
WinFormsCoreTest.zip
@Olina-Zhang could you please confirm the issue.
Thank you
@Russkie, this issue can repro in simple core app, the display of form icon using the icon from kirsan31's app is different from .Net framework app. Although size of Icons are same, but their bitDepth are different. Please see following screenshot:

.net Core and .net Framework apps:
CoreApp.zip
FrameworkApp.zip
Thank you Olina.
Just to confirm, does the issue only appear on W7? I tried it locally on W10 and I couldn't repro it.
@RussKie
Just to confirm, does the issue only appear on W7? I tried it locally on W10 and I couldn't repro it.
As I mentioned in first post, I can repro it on win7 and win10 (pro for Workstation 1903).
My apoligies, I misread the original report
I can reproduce it with the supplied icon:

However using other icons (from https://github.com/dotnet/winforms/tree/master/src/System.Windows.Forms.Design/src/Resources/System/WinForms/Design) everything is working as expected on W10E 1903:


@RussKie I think that it's very strange, that I didn't notice this in previous previews (I was using 5 and 7 before 9)...
I uninstalled preview9 and installed preview7. And yes on preview7 this icon displayed correctly!
Then I tried preview8 - same as preview9. So regression was introduce in preview8.
Then I tried preview8 - same as preview9. So regression was introduce in preview8.
Thank you for testing it
It looks like a regression in CoreFx in the way Icon loads the information from a stream of bytes.
I have used the repro app provided (thank you) and extended it to show-case the problem.
I have serialiesd two icons - the one provided with the repro (icon.ico) and another one from WinForms repo (good.ico) using the VS designer.
I have then used the base64 encoded strings to re-create icons.
My repro app can be found here - https://github.com/RussKie/Test-IconDeserialiser
@danmosemsft @ericstj could you please move the issue to the CoreFx repo
Looking at the changes I wonder if https://github.com/dotnet/corefx/commit/b75421a0035bf3a44e1f68447255470d57074dbb/src/System.Drawing.Common/src/System/Drawing/Icon.Windows.cs has introduced the regression, as it fits with the timeline
/cc: @JeremyKuhne
Looking at the changes I wonder if dotnet/corefx@b75421a/src/System.Drawing.Common/src/System/Drawing/Icon.Windows.cs has introduced the regression, as it fits with the timeline
Might have. I'll look into it.
Yep, I messed it up. :/ It's picking the first one that comes closest to the desired size, which in the case of this icon is the black and white 32x32 icon (which matches SM_CXICON x SM_CYICON). I'm fixing it, but I'm not entirely sure when it will make it to official builds.
You can hack around it by stripping the other colors out or making sure the 32bit one is first in the icon.
You can hack around it by stripping the other colors out or making sure the 32bit one is first in the icon.
Thanks for workaround, it's working.
Thanks for workaround, it's working.
Good to know. Unfortunately we're too late to get the fix into the initial 3.0 release (only a little over a week away), but it will definitely get fixed in 3.0.
Fix is in master (5.0), 3.0 port issue is linked, will close once we port to 3.0.
@JeremyKuhne do you know if the fix has been ported to 3.0?
https://github.com/dotnet/corefx/issues/41068 is tracking getting this fix in post GA. It will be one of the first servicing fixes we take.
Thank you Eric.
Verified this bug in .Net Core SDK 3.1.100-preview1-014066 build from release branch. This bug is fixed. Please see following screenshot:

This has been merged into .NET Core 3.0 and will show up in the next servicing release.
Most helpful comment
Fix is in master (5.0), 3.0 port issue is linked, will close once we port to 3.0.