Share via

Consume System.Drawing.Common package in Xamarin Android app?

  • Article

Question

Thursday, January 31, 2019 11:03 PM

My rendering code is now ported to .Net Standard 2.0 assemblies for portability. Next step is to consume said assemblies in a Xamarin Android app.

However I do not seem to be able to consume for example the System.Drawing.Graphics type in my Xamarin code, even though I have added a reference to the System.Drawing.Common package.

Am I attempting the impossible? Must anything System.Drawing.Common be completely encapsulated in my .NET Standard assemblies? Or is there a viable workaround?

All replies (12)

Friday, February 1, 2019 8:18 AM

Xamarin use Mono instead of .Net, the difference between them should be clear. Mono code and .Net are almost identical, they can even be compatible with each other (.net library can be mono-referenced and used), but Mono is a separate cross-platform library. You could refer to the document: https://www.mono-project.com/docs/about-mono/compatibility/. Not all the .Net code could be used in Mono.

System.Drawing.Graphics does not exist in Xamarin, as it conflict with Android.Graphics. You could use Android.Graphics in Xamarin.Android instead.

Friday, February 1, 2019 8:23 AM

@YorkGo - thanks for the tip, but Xamarin.Android is not portable code. The whole point (for me) of going to .Net Standard and accompanying System.Drawing.Common package is to have portable rendering code, for all platforms supported by .Net Standard. Note - this is imaging, not UI.

Friday, February 1, 2019 8:35 AM

Install the System.Drawing.Common nuget package for your portable library should be work.

Friday, February 1, 2019 6:09 PM

@YorkGo once again appreciate the tip. That was my thinking too, but System.Drawing.Graphics is not resolved even with System.Drawing.Common package added.

My conclusion is that it seems to not be possible to reference any symbols in the System.Drawing.Common assembly from my Xamarin code. And that's really what my question is about - should it be possible? Is there a workaround? Is what I am seeing a .Net Standard problem, or a Xamarin problem? Or am I making a user error?

FYI: As far as I can tell the System.Drawing namespace also exists in the Mono.Android assembly. All System.Drawing classes I can reference (Color, Point, PointF, Rectangle, RectangleF, Size, SizeF) originate in the Mono.Android assembly.

For anyone attempting to reproduce... my projects:

  • .Net Standard 2.0 assembly, that references System.Drawing.Common package, and exposes System.Drawing.Graphics as a parameter in an abstract class. This assembly builds fine. Currently building for x86, not sure if it matters at this stage.

        public abstract class MyClass
    {
        public abstract void MyMethod(System.Drawing.Graphics g);
    }

  • Xamarin Android class library that references the above assembly, and System.Drawing.Common package, and subclasses the abstract class above:

        public class MyAndroidClass : MyClass
    {
        public override void MyMethod(System.Drawing.Graphics g) // will not compile, Graphics not resolved
        {
        }
    }

VS2017 class view for the Xamarin project shows no symbols in the System.Drawing.Common project reference. In the .Net Standard project, all System.Drawing symbols are visible in the class view.

Friday, February 1, 2019 6:19 PM

Additionally I see a NuGet error: NU1201 Project mochro.android is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Project mochro.android supports: monoandroid81 (MonoAndroid,Version=v8.1)

I guess that confirms lack of compatibility.

Friday, February 1, 2019 9:09 PM

Found this doc page that sheds some light on the situation. Not sure yet to what degree it is relevant.

/en-us/xamarin/xamarin-forms/internals/net-standard

Tuesday, February 5, 2019 10:20 PM

After some research I concluded that this is due to a problem in the net core. System.Drawing.Common.dll should be present in my deployed app folder on Android, but it's not. Manually adding it seemingly eliminates the symptom (but exposes another symptom).

The bug report is here: https://github.com/dotnet/corefx/issues/29858 Solution seems to be targeted for .Net Standard 3.0.

Wednesday, February 6, 2019 3:49 AM

I finally got PlatformNotSupportedException from System.Drawing.Common.dll. Pretty clear sign. I have to write my own rendering primitives if I want portable code.

Saturday, July 6, 2019 1:57 AM

@larsv Sorry, I am late to the game, but I just had another customer bring this up in a support case.

Yes, only a very small bit of System.Drawing is available in Xamarin.Android or Xamarin.iOS as you noted above.

So yes, Xam.Android and Xam.iOS are not supported platforms, even though they are meant to be able to consume .NET Standard 2.0 assemblies, which System.Drawing.Common nuget package presents itself as supporting .NET Standard 2.0, that does not really seem to be the case. I think that System.Drawing.Common should not represent itself as being .NET Standard 2.0 compliant.

When looking in the nuget package for System.Drawing.Common, there are folders for MonoAndroid, MonoTOuch, xamariniOS10, xamarinmac20, xamarintvos10 and xamarinwatchos10, but all of those folders just have empty .dlls (0 bytes) named . Only the net461 and netstandard2.0 folders have System.Drawing.Common.dll files that are > 0 bytes.

Saturday, July 6, 2019 2:34 AM

I think this is the github filed bug that directly relates to this issue: https://github.com/dotnet/corefx/issues/31851 and https://github.com/dotnet/corefx/issues/28886#issuecomment-379315935 and https://github.com/mono/mono/issues/8089

Maybe a workaround here: https://github.com/mono/mono/issues/8089#issuecomment-389739210

(I have not tested workaorund)

Monday, March 30, 2020 7:41 PM

Today, I installed the System.Drawing.Common package ver 5.0 preview in visual studio 2017 and found that no Graphics class available, then I installed the CoreCompat.System.Drawing 1.0 beta instead and try to reproduce the error. So far the build and deployment without any problem. I'll report any further issues here...

Monday, March 30, 2020 8:05 PM

Cool. Let's see if it actually runs and on which platforms, that's where I encountered problems. I ended up using Skia for the rendering primitives I needed (some region/path algebra). But a true CLR implementation would be massively preferred, interop and c++ libs is quite the hassle in cross platform projects.