Add unimplemented types for deprecated UI controls #3783
Comments
msneijders
added
the
api-suggestion
|
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 ... |
merriemcgaw
added
the
blocking-migration
|
@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? |
dotnet-policy-service
bot
added
the
🚧 work in progress
Tanya-Solyanik
added
api-ready-for-review
|
Bringing the types and members back to look like they did in .NET Framework is blanket approved. The "new" types/members being declared as Obsolete with EditorBrowsable(Never) and Browsable(false) seems like goodness. While the obsoletion message makes sense to be different for each type/member (as appropriate), they should all use the same diagnostic ID as they were made obsolete in the same wave, and there's no reason to opt in to only parts of them. [Obsolete(
"ContextMenu and its related types has been deprecated. Use ContextMenuStrip instead.",
error: false,
DiagnosticId = WFDEV###,
UrlFormat = "https://aka.ms/winforms-warnings/{0}")]
[EditorBrowsable(EditorBrowsableState.Never)]
[Browsable(false)]
public partial class ContextMenu : Menu
{
public ContextMenu() : base(items: null) => throw new PlatformNotSupportedException();
} |
bartonjs
added
api-approved
dotnet-policy-service
bot
added
the
🚧 work in progress
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
Re-add the previously removed types as "empty" placeholder types that provide binary compatibility, just so old libraries can load these types in runtime, then my solution conversion to .NET5 would be so much easier.
An alternative would be to provide the obsolete types with empty implementations in a new assembly and enable type forwarding to that assembly. That would allow 3rd parties to provide custom implementations if needed in an assembly with a higher version number. However, that wouldn't work for the obsolete properties on the existing types (Control.ContextMenu) and we hadn't received request for that in 5 releases of .NET.
History
WinForms had documented some APIs as obsolete in NETFX 2.0, we shipped them in .NET3.0, then removed them completely in .NET3.1 - Windows Forms breaking changes - .NET | Microsoft Learn.
Previous request to restore these types - #5368
API proposal
Add the following types to System.Windows.Forms assembly.
This is the list of all removed public or protected types generated by the App Compat tool when matching .NET Framework 4.8.1 to the NET10.0 version.
Additionally, re-add the following methods that were using the removed types.
public partial class Form : ContainerControl { [Obsolete("MainMenu is not supported. Use MenuStrip instead.", false, DiagnosticId = "WFDEV007", UrlFormat = "https://aka.ms/winforms-warnings/{0}")] [System.ComponentModel.Browsable(false)] [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)] public MainMenu Menu { get { throw null; } set { } } [Obsolete("MainMenu is not supported. Use MenuStrip instead.", false, DiagnosticId = "WFDEV007", UrlFormat = "https://aka.ms/winforms-warnings/{0}")] [System.ComponentModel.Browsable(false)] [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)] public MainMenu MergedMenu { get { throw null; } } } public partial class Control : System.ComponentModel.Component, IDropTarget, System.ComponentModel.ISynchronizeInvoke, IWin32Window, System.ComponentModel.IComponent, IDisposable, IBindableComponent { [Obsolete("ContextMenu is not supported. Use ContextMenuStrip instead.", false, DiagnosticId = "WFDEV005", UrlFormat = "https://aka.ms/winforms-warnings/{0}")] [System.ComponentModel.Browsable(false)] [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)] public virtual ContextMenu ContextMenu { get { throw null; } set { } } [Obsolete("ContextMenu is not supported. Use ContextMenuStrip instead.", false, DiagnosticId = "WFDEV005", UrlFormat = "https://aka.ms/winforms-warnings/{0}")] [System.ComponentModel.Browsable(false)] [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)] public event EventHandler ContextMenuChanged { add { } remove { } } [Obsolete("ContextMenu is not supported. Use ContextMenuStrip instead.", false, DiagnosticId = "WFDEV005", UrlFormat = "https://aka.ms/winforms-warnings/{0}")] [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)] protected virtual void OnContextMenuChanged(EventArgs e) { } }new PlatformNotSupportedException(), default constructors are avoided by introducing private constructors if needed.[EditorBrowsable(EditorBrowsableState.Never)]attribute that hides them from the intellisense. Type names can be typed in by the developer and then intellisense would show the same members as it did for .NET Framework projects.[Browsable(false)]attribute to not show custom control properties of these types in the property browser.Example
Controlfor example) are not re-introduced even if they had been overridden in the past because they are not required for binary compatibility. An exception is properties or events that were decorated with[EditorBrowsable(EditorBrowsableState.Never)]in .NET Framework, as we don't want to show in intellisense members that have not been shown in the past.defaultor doing nothing.PlatformNotSupportedExceptionfor consistency.defaultvalue.Use Case
.NET applications can reference .NET Framework 3rd party libraries that use these types. Code will JIT and if the unsupported code is executed, it will throw an exception that can be caught instead of JIT throwing a missing member exception. For example:
To review
Compare the .NET Framework API in these classes - netfx.txt
To the .NET10 API surface generated by the same App Compat tool - review.txt
The text was updated successfully, but these errors were encountered: