Winforms: Remove deprecated controls

[RussKie]

Problem description:

The following types have been deprecated in .NET Framework:

• https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/DataGrid.cs (e.g. deprecation warning)
• https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/Menu.cs
• https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/MenuItem.cs
• https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/MainMenu.cs
• https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/ContextMenu.cs

However this fact was overlooked during the migration, and the types were brought into .NET Core 3.0.

Expected behavior:

The types are not available to consumers via intellisense.

[hughbe]

Are we knowingly breaking source compatibility with .NET?

[RussKie]

Yes. These controls technically have been deprecated since .NET 2.0 (circa 2005) and have been removed from the VS Designer Toolbox.
It was an oversight that we ported these in 3.0.
There will be more official comms coming from Olia and/or Rich.

[chylex]

Have the controls intended to replace these ever reached the look & feel of native Windows controls? I specifically use MainMenu and ContextMenu in apps targeting .NET Core 3.0 because the -Strip controls have always looked completely out of place. If there's no easy alternative to get native-like controls in 3.1, then the update is a dealbreaker for me.

[RussKie]

You're welcome to raise a new issue about making controls look Windows native. An associated PR will also be appreciated.

[merriemcgaw]

@chylex I'm interested to know what the differences are in the newer OSes that make the -Strip controls look completely out of place? What OS are your apps targeting? There may be some improvement possibilities there. File and issue with screen grabs and I'm happy to have the team take a look.

[chylex]

Alright, is there no way .NET Core can be backwards compatible? While testing this, I installed 3.1.0 by accident, which crashed because of the missing controls, which I suppose is expected, but then it wouldn't even let me install 3.0.0 without uninstalling 3.1.0 first.

If I have to tell people they must uninstall 3.1.0 and install 3.0.0 to use my app, and then reinstall 3.1.0 again if they want to use other new apps, I might as well revert back to .NET Framework for stability.

[chylex]

Filed #2476 @merriemcgaw, thanks for looking into it.

[RussKie]

If I have to tell people they must uninstall 3.1.0 and install 3.0.0 to use my app, and then reinstall 3.1.0 again if they want to use other new apps

It is possible to create self-contained apps, so your users will be able to run your apps without needing to install anything other than your app. You can find more info: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#compiledeploy

[Jehoel]

@merriemcgaw The old Menu class wrapped Win32/User32’s native window menubar, whereas MenuStrip (and the other FooStrip controls) were self-windowed WinForms controls that performed their own rendering and layout in managed code and didn’t integrate with the system. They looked great on Windows XP back in 2005 only because the WinForms assembly came with its own manually-defined colour-schemes. Since Vista they’ve looked out-of-place and is why I preferred Menu.

Fundamentally, it’s not because that Menu looks native, it’s because it is native.

Having to use MenuStrip is like having to use Java’s Swing or WPF - users notice that the controls/widgets just don’t feel the same as native (e.g. MFC) applications - and also that by not using native controls / OS GUI features we miss out on OS-provided improvements like textbox spell-checking or animated buttons, and so on.

In your post, you asked how the WinForms team can make MenuStrip look native - but that’s committing yourself to a maintenance treadmill. Why burden yourself with having to tweak MenuStrip every time the UX designers in OSG make changes in future releases of Windows when WinForms users could just automatically inherit those changes by using native widgets?

[LordBenjamin]

This breaks the Telerik UI for WinForms library, which is still using ContextMenu at least. I've logged a ticket with them.

Edit: Telerik confirmed that their 2020 library release will be 3.1 compatible and use ContextMenuStrip. This is due mid-January.

Although .NET Core 3.0 is (accidentally!) compatible, it is not an LTS release and will be out of support in the next 3 months. This would also be a concern for a self-contained deployment.

[ayoung-cforp]

@RussKie

Yes. These controls technically have been deprecated since .NET 2.0 (circa 2005) and have been removed from the VS Designer Toolbox.
It was an oversight that we ported these in 3.0.

I'm not sure what "technically deprecated" means, but the documentation for .NET Framework 4.8's ContextMenu clearly states:

_Although ContextMenuStrip replaces and adds functionality to the ContextMenu control of previous versions, ContextMenu is retained for both backward compatibility and future use if you choose._

MainMenu, DataGrid, and the others all say the same thing, and have since .NET 2.0.

I'm personally upset about this change; I've always hated MenuStrip and its ilk and never stopped using the originals. Now I've got 20 years of apps that can't be ported to .NET Core without redesigning all of the menus, toolbars, and context menus.

[LordBenjamin]

I note that the linked MSDN article also states:

Applies to
.NET Core
3.1 3.0
.NET Framework
4.8 4.7.2 4.7.1 4.7 4.6.2 4.6.1 4.6 4.5.2 4.5.1 4.5 4.0 3.5 3.0 2.0 1.1

Since the information on this page no longer applies to .NET Core 3.1, should a documentation issue be raised? I was confused earlier today, as I found the MSDN article before finding this issue.

[RussKie]

The docs have been updated.
The suggested replacements for the controls removed in .NET Core 3.1 can be found at https://docs.microsoft.com/dotnet/core/porting/winforms-breaking-changes#recommended-action.

[ayoung-cforp]

@RussKie I can't understand how this removal benefits your customers at all.

WinForms is already a legacy API to begin with. Wasn't the whole point of porting it to .NET Core so that customers could quickly port legacy apps away from .NET Framework? How exactly does removing the lesser-used components accomplish this?

[RussKie]

WinForms is already a legacy API to begin with.

What makes you think that?

Wasn't the whole point of porting it to .NET Core so that customers could quickly port legacy apps away from .NET Framework?

No, not quite.
One of the points was to _allow_ our customers to migrate any workloads they may have built on top of Windows Forms stack to .NET Core, if they desired.
However there is no requirement to migrate, .NET Framework isn't going anywhere in the observable future.
It is also incorrect to think that a developer can just replace "net4xx" with "netcoreapp3.1", hit a F5 and expect everything to work.

As far as the removal of outdated controls - there were few reasons, e.g.:

• these controls were not meeting accessibility requirements, which is a legal requirement for us;
• there was no VS Designer support.

To put in perspective, if you as a developer not using accessible controls are you providing a good service to your customers?

[ayoung-cforp]

WinForms is already a legacy API to begin with.

What makes you think that?

Because it's been in "maintenance mode" since at least 2014 (Microsoft's words, not mine) and Microsoft has stated that there are no plans to add new features.

these controls were not meeting accessibility requirements, which is a legal requirement for us;

Are there plans to remove these controls from .NET Framework as well because they do not meet your legal requirements?

if you as a developer not using accessible controls are you providing a good service to your customers?

I don't think using these components prevented us from providing good service to our customers. There is neither a legal requirement nor a moral obligation to use accessible controls when the customer does not require it.