Winforms: C1FlexGrid needs System.Drawing.Design.UITypeEditorEditStyle in System.Drawing

[Lohnegrim]

• .NET Core Version: 3.0 Preview1
• Have you experienced this same bug with .NET Framework?: No

I tried to convert one of our project to .Net Core 3.0 with WinForms, and it compiles and works fine for the most parts, but one of the external components(C1FlexGrid) we use always throws a error:
System.TypeLoadException: Could not load type 'System.Drawing.Design.UITypeEditorEditStyle' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Even if I add a different Assembly that Implements 'System.Drawing.Design.UITypeEditorEditStyle' then the Error Persists.

Actual behavior:
System.TypeLoadException: Could not load type 'System.Drawing.Design.UITypeEditorEditStyle' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at #s5.#m7.#R6(Int32 #j, Int32 #l)
at #s5.#Ojb.HitTest(Int32 #zq, Int32 #rP)
at #s5.#Ojb.#8ib(MouseEventArgs #tQ)
at C1.Win.C1FlexGrid.C1Flex
GridBase.OnMouseMove(MouseEventArgs e)

Expected behavior:
No Error

Minimal repro:
vbc.zip
I have attached a Sample Project, if it doesn't work, then you could try to download a trial from https://www.grapecity.com/en/download/componentone-studio and folow these steps to recrerate the sample:

1. dotnet new winforms
2. Edit 'Form1.Designer.cs' and add these lines at the end of 'InitializeComponent':
   C1.Win.C1FlexGrid.C1FlexGrid fg = new C1.Win.C1FlexGrid.C1FlexGrid();
   this.Controls.Add(fg);
   fg.Dock= System.Windows.Forms.DockStyle.Fill;
   fg.BringToFront();

[KlausLoeffelmann]

Hi @Lohnegrim,

the C1FlexGrid assembly you used: Is that a classic framework or a .NET Core assembly?
(If that would be a classic framework assembly/component, the behavior is expected since both assembly types core/classic are not compatible).

[Lohnegrim]

Hi @KlausLoeffelmann,

the C1FlexGrid assembly you used: Is that a classic framework or a .NET Core assembly?
It is the classic Framework.

(If that would be a classic framework assembly/component, the behavior is expected since both assembly types core/classic are not compatible).
Is, or will/should/may it be compatible in the future, or a will workaround for missing types like this?

[KlausLoeffelmann]

Is, or will/should/may it be compatible in the future, or a will workaround for missing types like this?

Well, no. Those are different platforms which cannot be made compatible. It is their nature that they aren't compatible. That said, there may be a good chance that your control provider (which is Component One I assume?) might be providing a version for WinForms Core in the future. You might want to check with them.

I am closing this.

[Lohnegrim]

Sorry for the late response,
I will try to contact them, but from past experience with them I have no hope for that.
So that means there will always be some assemblies that have to be recompiled to be compatible. (Even if no code Change is required)
Also when we cannot contact original provider?
So it will not be possible wot workaround this by using System.AppDomain.TypeResolve, AppDomain.AssemblyResolve or similar?

[SlavaB]

Hi @Lohnegrim,

the C1FlexGrid assembly you used: Is that a classic framework or a .NET Core assembly?
(If that would be a classic framework assembly/component, the behavior is expected since both assembly types core/classic are not compatible).

It seems like this is very incompetent answer. C1FlexGrid uses the standard WinForms classes. In particular System.Drawing.Design.UITypeEditorEditStyle should be already ported to Microsoft.WindowsDesktop.App . But this still has not been done.

[AdamYoblick]

@dreddy-work Did System.Drawing.Design ever get ported to net core 3? I'm looking at the winforms source and it looks like we only have a facade to primitives, which have moved into a package we now consume.

Are there any plans to port System.Drawing.Design.UITypeEditorEditStyle?

[IrinaPykhova]

the C1FlexGrid assembly you used: Is that a classic framework or a .NET Core assembly?
(If that would be a classic framework assembly/component, the behavior is expected since both assembly types core/classic are not compatible).

do you need us to give you links to blog posts or videos where MS declares compatibility and support of scenarios when WinForms and WPF controls can be used as is in .Net Core 3 applications?
The most of our controls just work. System.Drawing.Design.UITypeEditorEditStyle is a very simple enumeration which we use in public API in different assemblies. In classic framework it is defined in System.Drawing.dll assembly. We are expecting that it should be supported in .Net Core 3. It is really odd to build special version of binaries due to single absent enum. Especially because there are several threads here, where .Net Core team discusses that it should be included.
We can give you sample project demonstrating the problem.
Please open this issue and let us know when it is expected to be fixed.

[IrinaPykhova]

@Lohnegrim, thank you for posting this. We think that this issue should be fixed on MS side.

[KlausLoeffelmann]

@IrinaPykhova: A sample would be helpful to avoid misunderstanding - and obviously I have been answered prematurely. Sorry for that. I will reopen, and will discuss this with the team, especially with the aspect of breaking changes we need to make for future improvements, and the consequences this will have in backwards compatibility.

[SlavaB]

@KlausLoeffelmann , please take a look to the attached sample.
TestApp.zip

There are two projects in the solution that use one Form with C1FlexGrid control. The project with .Net Framework 4.7.2 starts successfully. The project with .Net Core 3 raises exception about missing System.Drawing.Design.UITypeEditorEditStyle.

[KlausLoeffelmann]

Hey guys,

thanks for your patients, here. I talked with the team, and you should see the missing method in one of the upcoming releases. When you can confirm that this issue has been resolved, quickly ping me, and I close this. If this is not resolved during next week, also ping me, and I will investigate. Thanks!

[SlavaB]

@KlausLoeffelmann , thanks, I will track the changes.
Note, the problem is that System.Drawing.Design.UITypeEditorEditStyle enum is now in System.Windows.Forms assembly. But the enum was in System.Drawing assembly earlier, in .Net Framework.

[KlausLoeffelmann]

@dreddy-work?

[SlavaB]

@KlausLoeffelmann, any updates on this?

[KlausLoeffelmann]

@dreddy-work, @zsd4yr - shouldn't this be in by now?

[merriemcgaw]

@JuditRose assigning this to you as you're working on porting a bunch of the editors in now.

[prabhakarGC]

Do we know when this fix will be available?

[zsd4yr]

@JuditRose can update on status

[JuditRose]

This enum exists in System.Windows.Forms: https://github.com/dotnet/winforms/blob/82634b7a59c5d1253fc3ee2107092868546c6f79/src/System.Windows.Forms/src/System/Drawing/Design/UITypeEditorEditStyle.cs
@Lohnegrim @IrinaPykhova @prabhakarGC Can you please double check if you reference it the right way?
Have you seen the message from @SlavaB, commented on Jan 28?

Note, the problem is that System.Drawing.Design.UITypeEditorEditStyle enum is now in System.Windows.Forms assembly. But the enum was in System.Drawing assembly earlier, in .Net Framework.

Is there a reason why you are not using the System.Windows.Forms assembly?

[OliaG]

Do we know why it was moved to the new place? @merriemcgaw @dreddy-work?

[IrinaPykhova]

@JuditRose, we don't want to rebuild all our assemblies under .Net Core 3. We are trying to use .Net 4.0 binaries as is in .Net Core 3 application. Almost everything else just works. But in such scenario we got runtime exception that this enum does not exist. I think the problem is that in full Framework and in .Net Core 3 it is placed into different assemblies. Don't you have some option to set mapping to workaround such problems?
You can check sample (TestApp.zip) attached by SlavaB on January 21st to see the problem

[SlavaB]

It seems the issue with UITypeEditorEditStyle had been fixed. I checked it with SDK 3.0.100-preview4-010999.

[merriemcgaw]

Great! I will close this issue then.