-
Notifications
You must be signed in to change notification settings - Fork 961
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
Add unimplemented types for deprecated UI controls #3783
Comments
I don't think this will work, I'm not 100% certain but I think loading types is lazy, so it already will only load them at the point they are used. However if they are used then it typically will be in the form/control constructor (in the generated designer code part), so throwing an exception will mean you have that exception being thrown in your third party form/control constructor. That probably is not helpful and just changes the error you are getting?
I suspect if these are WinForms based libraries you'll have a hard time to get this working properly in .NET Core, there are subtile changes like the default font being different which mean that it often needs code adjustments to work well on .NET Core. It would have been nice to be able to just run Desktop Framework WinForms code on .NET Core but the decision was made against that and I don't think it can be changed at this point. |
In general you are right and this will not work -- but all my 3rd party libraries are using the "new" controls that have replaced the deprecated ones -- it is just that they kept supporting the deprecated ones with code like "if (this.ContextMenuStrip != null) { ..use new control...} else if (this.ContextMenu != null) { ..keep it backwards compatible...}. Now if ContextMenu just worked and returned null as I do not use it, it would have worked in runtime -- now it gives "cannot find/load type ContextMenu. Making it hard to upgrade existing winforms applications to .NET5 is a mistake in my opinion. (it all worked nicely in .NET Core 3.0, why change that?) |
these controls already were removed in .NET Core 3.1 (the LTS version of 3.0 - .NET Core 3.0 is already out of support) |
Exactly, that is why I cannot use .NET Core 3.0, not shipping something that is out of support to my customers. |
@msneijders have you tried creating dummy classes for these deprecated types in your assembly, and type-forwarding them to the Windows Forms assembly? |
@teo-tsirpanis I did not try this yet, but I will soon, thank you for this suggestion. |
Type-forwarding does not seem like a workaround -- I think forwarding needs to be done from the System.Windows.Forms assembly. |
Hmm, doesn't it work the other way around? There's an attribute named It is written like this: |
This comment has been minimized.
This comment has been minimized.
@msneijders said he doesn't himself use these legacy controls in application code. He uses an old control library wich supports both the legacy and the new controls, but the legacy control code path will never be executed. We don't care about the compiler recognizing them. All we want is a runtime trick to not crash the loader because of a couple of classes were not found. |
This comment has been minimized.
This comment has been minimized.
We also experienced this. Added dotnet/runtime#41088 , but ... It is frustrating however that net core 3.0 had the types ... |
@LeafShi1 let's get this on your team's radar, so that we can help customers do their migrations. |
@LeafShi1 @Epica3055 @SimonZhao888 @ricardobossan, here are the steps to start with -
|
@Tanya-Solyanik Have all the obsolete controls been open sourced? |
@paul1956 - DataVisualization is out of scope of this item. This item is only about public APIs that were removed from System.Windows.Forms.dll |
We have done the migration by reimplementing missing functionality. |
@JensNordenbro I totally understand what you're saying here! Note that you can enable .NET updates in Microsoft Update so that servicing updates are automatically installed. We don't have an automatic upgrade between major versions, however, and you're right about the 3-year LTS cycle. We do this to help facilitate our customers keeping updated with both new functionality and the latest perf and security updates. /cc: @jamshedd |
Yes @merriemcgaw, I know! Maybe it is enough, however if you want to grab the late runners I think introducing a new tier of LTS of 5 years or something is needed. Polyfilling api:s might not be the real problem. - It helps though. |
|
I don't think thats complete? I remember the discussion of removing the old menu APIs. So unless I'm misunderstanding what you're trying to do, shouldn't those appear on the list too? |
Is your feature request related to a problem? Please describe.
I am migrating a large Winforms .NET Framework 4.7.1 solution to .NET 5.0 (preview 8). My biggest pain are the deprecated UI Controls like ContextMenu and related types like 'MenuMerge'. Not because of my own code, I don't use them anymore. But we use quite some 3rd party libraries who still have references to these deprecated types. Libraries that are not so much in development anymore.
For example a library supports both ContextMenu and ContextMenuStrip. I don't use ContextMenu, so this is always a null reference, but because the type ContextMenu cannot be loaded from System.Windows.Forms.dll using .NET5 all these 3rd party libraries are broken in runtime.
Describe the solution you'd like and alternatives you've considered
If instead of completely removing these deprecated types, it was replaced with "empty" placeholder types, maybe throwing a 'DeprecatedException' when a method of it is called, just so old libraries can load it in runtime, then my solution conversion to .NET5 would be so much easier.
Will this feature affect UI controls?
No?
The text was updated successfully, but these errors were encountered: