[Bug Suspected] ImageFormat's "ToString" comparation error

[ghost]

Let's get started with a very simple demo:

1. Create a demo console application and referring net 4.6 framework, with the "System.Drawing" namespace added in.

2. Download or create a file of jpg.

3. Now let's import the file directly into the Image and do this following by:

Image img = Image.FromFile("c:\\test.jpg"); Console.WriteLine(img.RawFormat.Equals(ImageFormat.Jpeg));

Now the answer is "True", and the ImageFormat's Guid for "JPEG" is "{b96b3cae-0728-11d3-9d7b-0000f81ef32e}". The same answer is also for "Equals".

HOWEVER in "ToString" method, the expected result should be "Jpeg" as the output. But I didn't see that, and instead the result is:

[ImageFormat: b96b3cae-0728-11d3-9d7b-0000f81ef32e]

Now let's deeply go into the code (to here), the original source code is from: https://referencesource.microsoft.com/#System.Drawing/commonui/System/Drawing/Advanced/ImageFormat.cs,b96b3cae-0728-11d3-9d7b-0000f81ef32e,references

public override string ToString()
{
if (this == memoryBMP) return "MemoryBMP";
if (this == bmp) return "Bmp";
if (this == emf) return "Emf";
if (this == wmf) return "Wmf";
if (this == gif) return "Gif";
if (this == jpeg) return "Jpeg";
if (this == png) return "Png";
if (this == tiff) return "Tiff";
if (this == exif) return "Exif";
if (this == icon) return "Icon";
return "[ImageFormat: " + guid + "]";
}

Why do we say "this == another type of ImageFormat" without overridding the operator "=="? And from this demo can we make sure that this is a bug and should be fixed?
And what's more——Why not use "if……else if……else……" instead of multiple "if" here?
PS：I didn't find the ImageFormat.cs yet, though I did a full research.

[JonHanna]

Only a small part of the System.Drawing namespace is in corefx, and ImageFormat isn't part of that. If this is a bug it's only in .NET 4.6 so it should be reported at http://connect.microsoft.com/

[karelz]

Correct, we do not track Desktop/full .NET Framework bugs on GitHub.

[ghost]

@JonHanna ：For 4.6 is only my sample and later I found that this bug DID exist in almost all kinds of known versions of frameworks since 2.0. And I've checked the issue, the following versions have such a problem (My PC is x86, x64 isn't checked yet).

2.0, 3.5, 4.6

[JonHanna]

It's not in corefx though.

[ghost]

So you mean that I can also directly report this issue on Microsoft's Connect platform of bugs, no matters how many versions it has?

[JonHanna]

It's likely a good idea to include as much information about it as you can. Really, I don't know much about Connect except from having reported a couple of issues there in the past myself. With one of those the method in question was made later part of corefx and I was able to do something more proactive about it. Since ImageFormat isn't in corefx (yet, anyway) there's nothing that can be done about it here.

[ghost]

OK, I'll have a try.
Thanks @JonHanna.

[azyobuzin]

ImageFormat is now in corefx. Can we reopen this issue?

[danmoseley]

@safern can suggest whether fixing this would be unacceptably breaking.

[safern]

@safern can suggest whether fixing this would be unacceptably breaking.

I don't think this would be breaking as we don't use the ImageFormat.ToString() to compare anything, we do it directly we .Equals method that compares the Guid of the ImageFormat directly. I think the fix would be instead of doing this == s_jpeg to either do this.Equals(s_jpeg) or this.Guid == s_jpeg.Guid which is what .Equals does, compare the guids.