Add support for System.Drawing on Windows. #20593

mellinoe · 2017-06-01T21:14:28Z

This change adds a new library, System.Drawing.Common, which supports a large subset of the System.Drawing API. It is a direct port of the code from the .NET Framework codebase. The code has been cleaned, formatted, and sanitized to match the code style of corefx, but is otherwise very
similar to the .NET Framework version. There are a few key differences:

TypeConverter's have been omitted for now. If we want to add these to .NET Core, we should add them to the TypeConverter library, rather than System.Drawing.Common itself. Note that there's already a few TypeConverter's for the types that are in System.Drawing.Primitives.
Some parts of the library do not respond to "System Events", because they are not yet implemented in .NET Core. This means that fonts and colors will not automatically update when the system defaults change, as they do in .NET Framework. The code is still there, but behind the feature flag "FEATURE_SYSTEM_EVENTS".
Various attributes have been removed from the codebase, because they are no longer applicable. Examples:
- Designer-related attributes (DefaultProperty, DefaultEvent, Editor, etc.)
- CAS-related attributes. CAS-related method calls (Security demands and asserts) have also been removed.

There is still further cleanup that can be done in order to match the style and structure of corefx. For example, the interop code should be reorganized to match other BCL libraries.

NOTE: This implementation will only work on Windows, and not in UWP. This is a strictly compatibility-driven feature. Any changes made to it should not significantly diverge from the .NET Framework implementation. Libraries should only take a dependency on System.Drawing.Common if they
are relying on legacy components from .NET Framework; newly-written code and features should rely on modern alternatives.

This change adds a new library, System.Drawing.Common, which supports a large subset of the System.Drawing API. It is a direct port of the code from the .NET Framework codebase. The code has been cleaned, formatted, and sanitized to match the code style of corefx, but is otherwise very similar to the .NET Framework version. There are a few key differences: * TypeConverter's have been omitted for now. If we want to add these to .NET Core, we should add them to the TypeConverter library, rather than System.Drawing.Common itself. * Some parts of the library do not respond to "System Events", because they are not yet implemented in .NET Core. This means that fonts and colors will not automatically update when the system defaults change, as they do in .NET Framework. The code is still there, but behind the feature flag "FEATURE_SYSTEM_EVENTS". * Various attributes have been removed from the codebase, because they are no longer applicable. Examples: * Designer-related attributes (DefaultProperty, DefaultEvent, Editor, etc.) * CAS-related attributes. CAS-related method calls (Security demands and asserts) have also been removed. There is still further cleanup that can be done in order to match the style and structure of corefx. For example, the Interop code should be reorganized to match other BCL libraries. NOTE: This implementation will only work on Windows, and not in UWP. This is a strictly compatibility-driven feature. Any changes made to it should not significantly diverge from the .NET Framework implementation. Libraries should only take a dependency on System.Drawing.Common if they are relying on legacy components from .NET Framework; newly-written code and features should rely on modern alternatives.

stephentoub · 2017-06-01T21:19:12Z

Thanks, @mellinoe. What kind of / level of code review are you looking for on this?

mellinoe · 2017-06-01T21:26:46Z

@stephentoub I think there's a few things I'd like to accomplish before being "ready to merge":

Make sure the build configurations are specified correctly for System.Drawing.Common.
Make sure that .NET Framework code built against System.Drawing will work / type-forward correctly with this new library. This needs a shim project to be configured (I think).
Finalize a list of code style and refactoring work items that should be done as a follow-up. I just spent a couple full days getting to this state, but this code is very old and could still use some more work. I've compiled a list as I worked, but I'm sure that I've not caught everything that needs fixed.

danmoseley · 2017-06-02T02:00:07Z

@mellinoe what is your test strategy? Does Mono have much we can reuse? Have you taken a look at what Desktop has?

mellinoe · 2017-06-02T17:34:02Z

@danmosemsft Yes, mono has tests that we will re-use. .NET Framework does not have great test assets -- they are mainly for higher-level components like WinForms which indirectly test System.Drawing.

hughbe · 2017-06-05T03:45:51Z

I could look in to adding/porting some Mono tests if you're not doing so already

hughbe · 2017-06-05T03:47:19Z

src/System.Drawing.Common/src/System/Drawing/Printing/PaperSourceKind.cs

+        /// </devdoc>
+        Manual = SafeNativeMethods.DMBIN_MANUAL,
+
+        /// <include file='doc\PaperSourceKind.uex' path='docs/doc[@for="PaperSourceKind.Envelope"]/*' />


Do we usually have doc-comments like this?

We don't. Cleaning these up is on my list of follow-up items, which I'll make sure to file tomorrow. Unfortunately, this style of comment is pretty common in our .NET Framework codebase; I'm not even sure what the names and paths refer to.

mellinoe · 2017-06-05T08:29:37Z

I could look in to adding/porting some Mono tests if you're not doing so already

Sounds great; I could definitely use some help with that. I ported a select few test cases and tried running them against the implementation here, but there's still a ton of work to be done there. Porting from Nunit to Xunit was fairly annoying and time-consuming, and after that there were still minor differences that caused lots of tests to fail. I will file another issue tomorrow about this so we can try to plan it out and split up the work.

mellinoe · 2017-06-05T20:23:01Z

Merging this in now. I've filed several follow-up issues for further System.Drawing work:

weshaggard · 2017-06-06T17:05:23Z

src/System.Drawing.Primitives/src/System/Drawing/KnownColor.cs

@@ -7,7 +7,7 @@
 namespace System.Drawing
 {
    [SuppressMessage("Microsoft.Design", "CA1008:EnumsShouldHaveZeroValue")]
-    internal enum KnownColor
+    public  enum KnownColor


Adding this as a public type in System.Drawing.Primitives is going to cause issues with netstandard. In particular currently the NETStandard.Library contains a shim for System.Drawing.Primitives so at a minimum we need to bump the minor version of System.Drawing.Primitives to ensure folks targeting .NET Core will get the later version.

(assuming we haven't already bumped the minor version, I didn't verify)

I haven't bumped the minor version; will do.

weshaggard · 2017-06-06T17:07:32Z

src/System.Drawing.Common/src/System.Drawing.Common.csproj

+    <Reference Include="System.Runtime.InteropServices" />
+    <Reference Include="System.ComponentModel" />
+    <Reference Include="System.ComponentModel.Primitives" />
+    <Reference Include="System.Security.Permissions" />


We should try to avoid depending on System.Security.Permissions.

@mellinoe looks like it's needed for two things -- a bunch of use of CAS types, which we should just rip out; and definition of PrintingPermission/PPAttribute, which is already in S.S.Permissions and we should just rip out. perhaps you could open an issue to do this, and remove this reference?

Cleaning up the unnecessary permissions stuff is on my list. I will track removing this reference entirely, as well. https://github.com/dotnet/corefx/issues/20706

weshaggard · 2017-06-06T17:11:05Z

src/System.Drawing.Common/dir.props

+  <Import Project="..\dir.props" />
+  <PropertyGroup>
+    <AssemblyVersion>4.1.0.0</AssemblyVersion>
+    <AssemblyKey>MSFT</AssemblyKey>


We should use the Open key for new libraries like this.

Will change.

weshaggard · 2017-06-06T17:11:35Z

@mellinoe do you also need follow-up items to enable packaging for this library when it is ready?

mellinoe · 2017-06-06T17:33:53Z

@mellinoe do you also need follow-up items to enable packaging for this library when it is ready?
Delete branch

@weshaggard I'll file an issue to track that explicitly.

dnfclas added the cla-already-signed label Jun 1, 2017

karelz added the area-System.Drawing label Jun 2, 2017

karelz added this to the 2.1.0 milestone Jun 2, 2017

karelz assigned mellinoe Jun 2, 2017

hughbe reviewed Jun 5, 2017

View reviewed changes

mellinoe merged commit e15746e into dotnet:master Jun 5, 2017

weshaggard reviewed Jun 6, 2017

View reviewed changes

qmfrederik referenced this pull request in mono/mono Jun 16, 2017

Use CoreFX sources for System.Printing (#5041)

831381c

devblackops mentioned this pull request Mar 30, 2018

Remove [System.Color] Warning? RamblingCookieMonster/PSSlack#60

Closed

mellinoe mentioned this pull request Jan 31, 2020

Support Full System.Drawing Functionality on .NET Core dotnet/runtime#21980

Closed

5 tasks

qmfrederik mentioned this pull request Jan 31, 2020

TypeConverters for System.Drawing dotnet/runtime#22324

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for System.Drawing on Windows. #20593

Add support for System.Drawing on Windows. #20593

mellinoe commented Jun 1, 2017

stephentoub commented Jun 1, 2017

mellinoe commented Jun 1, 2017 •

edited

Loading

danmoseley commented Jun 2, 2017

mellinoe commented Jun 2, 2017

hughbe commented Jun 5, 2017 •

edited

Loading

hughbe Jun 5, 2017

mellinoe Jun 5, 2017

mellinoe commented Jun 5, 2017

mellinoe commented Jun 5, 2017

weshaggard Jun 6, 2017

weshaggard Jun 6, 2017

mellinoe Jun 6, 2017

weshaggard Jun 6, 2017

danmoseley Jun 6, 2017

mellinoe Jun 6, 2017

weshaggard Jun 6, 2017

mellinoe Jun 6, 2017

weshaggard commented Jun 6, 2017

mellinoe commented Jun 6, 2017

Add support for System.Drawing on Windows. #20593

Add support for System.Drawing on Windows. #20593

Conversation

mellinoe commented Jun 1, 2017

stephentoub commented Jun 1, 2017

mellinoe commented Jun 1, 2017 • edited Loading

danmoseley commented Jun 2, 2017

mellinoe commented Jun 2, 2017

hughbe commented Jun 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mellinoe commented Jun 5, 2017

mellinoe commented Jun 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weshaggard commented Jun 6, 2017

mellinoe commented Jun 6, 2017

mellinoe commented Jun 1, 2017 •

edited

Loading

hughbe commented Jun 5, 2017 •

edited

Loading