-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to reference System.Design #79
Comments
Hi Joseph, Also if you haven't done it yet, I would suggest running Portability Analyzer that will show all APIs in your app that are not yet included in .NET Core 3.0. |
Hi Olia, Our applications depend on DevExpress's End User Report Designer (docs). DevExpress built it on top of the System.ComponentModel/IDesignerHost/CodeDOM set of abstractions, very much like the Windows Forms designer itself. This designer ships for our users at runtime (as the name suggests). We've written custom reporting elements that integrate with it. Since DevExpress based the designer heavily on System.Design, our integrations with the report designer are also tied to System.Design. We're hoping that this doesn't keep us from moving to .NET Core. In this report, see especially That's what DevExpress's code needs. Our code, which merely integrates with DevExpress's report designer, ends up directly using these types:
And these members:
|
Thank you, Joseph! I'll get our engineers to look at it and follow up with you. |
We have similar dependencies for our custom WinForms controls too. The missing API set is nearly identical. In our case they are design-time only and we have a build option to strip them out of release builds, so we are still able to run our application on .NET Core 3 alpha today (with some additional fixes discussed in the CoreFX repository issues). I suspect this will come up quite often and it has to be addressed in one way or another. I was hoping that this will eventually come later when the WinForms design-time support is brought in later preview. I'm taking a wait-and-see approach on this one, but wanted to express some support that the scenario is probably common. |
Thank you Filip! |
I think Ideally such should come in Windows Compatibility Pack for .NET Core, or Microsoft.WindowsDesktop.App. |
@lextm I was thinking System.Design should be part of |
Same here... In my case the missing types are:
|
We will be taking a look at porting these editors soon. |
@dreddy-work should we move this issue to dotnet/winforms? |
@livarcocc , yes please. we will be looking into these coming week. |
Just to be completely clear. My current issue is simply compiling custom property grid editors that inherit from the said This is not a VS designer issue, at least as far as I am concerned.. |
@damageboy , I understand. When we were porting editors to netcore, our analysis was, the above said editors will be used mostly at the design time and hence prioritized that way. Now that we see runtime usage for these editors, we are discussing to port these editors to net core in the coming weeks. |
Issue moved to dotnet/winforms #221 via ZenHub |
When converting the project to netcoreapp3.0 and keeping the
System.Design
reference, the compiler doesn't seem to see the reference:How will this work in the future?
(edit) This gets it to build:
But since System.Design is heavily used at runtime, I'm doubtful that the .NET Framework's System.Design will work.
The text was updated successfully, but these errors were encountered: