.NET 10

[helladen]

This moves the Eto Forms to .NET 10.

[cwensley]

Wow, that was fast! Thanks for the contribution. However, since .NET 8 is still in support until November 2026, I'd like to move the core projects to support both net8.0 and net10.0. Moving them directly to net10.0 means they won't be usable by net8.0 projects anymore.

In particular, this is what I'd propose:

• Eto: netstandard2.0;net8.0;net10.0
• Eto.Wpf: net462;net8.0-windows;net10.0-windows
• Eto.WinForms: net461;net8.0-windows;net10.0-windows
• Eto.Direct2D: net462;net8.0-windows;net10.0-windows
• Eto.macOS: net8.0-macos14;net10.0-macos14
• Eto.Mac64: netstandard2.0;net8.0;net10.0
• Eto.Gtk: netstandard2.0;net8.0;net10.0
• Eto.WinUI: net10.0-* is fine as it's not actually supported yet.

As for the test projects, I am okay if they target just net48 and net10.0*. We'll also have to update .vscode/launch.json to point to the new paths for the tests.

[helladen]

Thanks for the feedback, I added experimental fluent theme support. If you don't want it added, I can remove it.

[Serg-Norseman]

Is it possible to maintain the ability to build for net6.0 for another year or two?

I can't say the need is critical, but if the build remains limited to net8/10, it's concerning...

[cwensley]

@helladen, thanks for the updates. Yeah, I'd like the fluent theme support to be handled separately from this PR if possible. I've already experimented with it in #2735, and would like it to be part of adding theme APIs to Eto.

@Serg-Norseman I have no issues keeping net6.0 targets, it does not add much overhead tbh. Do know that zero testing will be done on it as it is out of support, but I would accept PR's that fix any issues of course.

[cwensley]

@Serg-Norseman to understand better, why would dropping the out of support .NET 6.0 targets be concerning? It ended on November 2024. Is this more from a linux point of view where updating built-in packages is not easily done on older distro versions?

[Serg-Norseman]

@helladen Sorry for the offtopic

@cwensley
I may remember something incorrectly or make mistakes. Therefore, please allow for any errors or inaccurate translations.

My concern stems from what I've seen in the news announcements from subscription to the dotnet repository, where each new version of dotnet removes some code for compatibility with older versions of Windows and other OSes (I'm not sure if this code removal is widespread or regular). As a professional developer, I understand this and fully support it. However, on Eto.Forms, I'm developing a pet project for end users in genealogy.

While on Linux and MacOS, I'm not concerned about the removal of legacy compatibility code—the users there are typically advanced and often at the forefront of innovation. For Windows, I have incredibly stubborn and obstinate users who are still using ancient versions of my program due to their reluctance to switch from, say, WinXP/Vista/7 (this is mostly due to conservatism, stubbornness, and a penchant for traditional, familiar tools, rather than financial solvency). Of course, such users are rare, and I don't focus on them at all. But things are already bad with Windows 10, too—it's already out of regular support.

I was planning to migrate my Eto.Forms-based project to .net8 in the next month or two. And I expect that some users will experience new problems even with this release, on old versions of Windows 10. I read that during the development of .net8-9, some compatibility with older versions of Win10 was simply removed (I don't know how accurate this is).

If I lose the ability to fix the issues or roll back to .NET 6, I'll likely lose some of my audience again, as happened every time I switched to a new framework version...

At the same time, I understand that for some projects with a tiny audience, your project can't support old, unnecessary compatibility for long.

[helladen]

Removed fluent theme, it's still pretty buggy with the controls. I think it might be best to handle this until it is complete by Microsoft.

[ktwrd]

Wouldn't updating this to NET10_0_OR_GREATER cause issues when compiled for .NET 8?

[captainjono]

I was just upgrading my app to dotnet10 and came across an issue where any calls to try and show a eto form would result in a UIThread exception... even though they were called on it correctly. So I appreciate the work on this! :D

[cwensley]

I was just upgrading my app to dotnet10 and came across an issue where any calls to try and show a eto form would result in a UIThread exception... even though they were called on it correctly. So I appreciate the work on this! :D

Hey @captainjono, I don't think anything regarding updating to .NET 10 would fix an issue like that. You likely have some code running on a non-UI thread. The only frameworks that allow that are WinForms and WPF, all others require all code to run on the UI thread. Eto itself has checks for this since 2.6.0. You can disable it with Application.Instance.UIThreadCheckMode