System.Drawing.Color does not exist in System.Drawing, but instead in OpenTK

[jamesmontemagno]

Steps to Reproduce

1. Try to use System.Drawing.Color on iOS
2. It requires OpenTK to be brought in

Expected Behavior

Since we conform to .NET Standard 2.0 which System.Drawing.Color lives in we should have this available in a non-third-party assembly.

Actual Behavior

OpenTK dependency is needed.

Environment

15.9

[VincentDondain]

Hi James,

Issue5273.zip

Here's a sample project showing this issue you're talking about but also showing it's actually the expected behavior with a counter example (:

I think there are a couple clarification needed (I needed some of them myself and asked Sebastien):

1. Xamarin.iOS does not "conform" to NetStandard in the sense that the Xamarin.iOS.dll is expected to include all the dlls needed for all the NetStandard APIs. Instead Xamarin.iOS provides the Facades with the type forwarders needed to find the actual dlls required for specific types.
   E.g:

   .class extern forwarder System.Drawing.Color
   {
       .assembly extern 'OpenTK-1.0'
   }
   

2. Xamarin.iOS and Xamarin.Android differ for historical reasons on where System.Drawing.Color is located. For some reason Android pulled that into their main dll and we have that in OpenTK. It's a shame it's not the same "behavior" but it would be breaking at this point for Xamarin.iOS to change that.
3. The Xamarin.iOS behavior of having to reference the OpenTK dll when a type can't be found is expected and the same thing would happen for System.Net.Http. That's the example I provided in the sample. The NetStandard library is working within the magical world of references (ref), everything works all the time, you're not expected to have the actual code (dlls). Whenever a consumer project is using that library, then you need the actual code (lib) and that's when things break if anything is missing.

Hope this clarifies the situation.

[mattleibow]

The issue with OpenTK is that it adds 2MB just to reference Color. I created a new project and built for release: 16MB. I then added a single line throw new Exception(System.Drawing.Color.Red.ToString());. Now it is 18MB with linking enabled.

When I open the .dll, it is not very linker friendly:

[VincentDondain]

@mattleibow yea that doesn't seem right. I opened a linker specific bug for that: #5275. More should probably be linked away and the use of Color only should make a tiny difference in the final app size.
However this doesn't change the answer I gave previously, we're not gonna move the types away from OpenTK.

Note: I cannot reproduce those 2MB increase numbers (much much less) but the issue seems still there anyway.

[mattleibow]

@VincentDondain Thanks for the info. I just realised that this issue is actually wrong.

So I reopened to restart the discussion from a different point of view - if I may :)

Why is the System.Drawing types in OpenTK? I understand legacy reasons, but is there a technical reason? What are the implications of creating a new assembly "System.Drawing" as one would expect and then type forward OpenTK and netstandard to that one?

With regards to "breaking changes", isn't this the reason type forwarding was invented - so that types can be moved. It has happened with types moving from System to System.Core and it didn't break the world.

[spouliot]

Why is the System.Drawing types in OpenTK?

That predates Xamarin. If you're curious you can dig git history - it's often funny :)

I understand legacy reasons, but is there a technical reason?

None that I can think of. The reason for having some other types (Point[F], Rectangle[F] and Size[F]) in the platform assemblies does not apply to Color. Beside having two separate discussions about it today I could not remember that it was located in OpenTK-1.0.dll

isn't this the reason type forwarding was invented

Partially, type forwarders solves part of the problem (i.e. it solves it at runtime, not build time). IOW this would result in the same situation you have right now - i.e. existing projects would not compile anymore (a breaking change, but not an API one) unless the new assembly is added as a reference. It's much easier to move things inside mscorlib (which was often done) or System.dll since they are always (or almost) already referenced by projects.

Still we're looking into using type forwarders (which will need some additional hacks to avoid breaking projects) as part of completing netstandard 2.1 support, which adds a few more types (converters) as we do not want the situation to get worse.

I'll also update our XAMCORE_4_0 (next, if ever, breaking changes) meta-issue to mention this.