Migrate to .NET 8.0
mrhelmut opened this issue · 17 comments
Intent
.NET 8.0 is going to release in just a few days from now (if not already released by the time of reading this) and is the next/current Long Term Support version of .NET.
We should migrate any and all projects and packages to this new standard as soon as possible so that this version may be the baseline of future MonoGame improvements for the next 2.5 years (duration of .NET LTS support).
Task is up for grab and should be accessible to first contributions.
Motivation
It is especially critical for having store-compliant Android and iOS support, as well as the full range of PublishAot support for desktop platforms (and in the future, consoles -- which for now are still on the .NET 4.5 BRUTE runtime).
@mrhelmut I can grab this if no one else has yet
@mrhelmut will this make it into the next MonoGame release?
It's been updated, think they were just waiting for release day (today) to test against the released LTS instead of the RC (release candidates)
Question: Is moving from net6 to net8 really required?
I mean, I understand needing to target Net8 because it might add some useful features to consoles/mobile.
What I don't understand is removing support for Net6.
I can't see why it would not be possible to support both frameworks, since it's common practice by most libraries to do multitargeting.
To give some context:
When monogame upgraded to net6 and we adopted it, we had to ask our clients in more than 30 hospitals to install the net6 runtime to support it, and it was unbearably costly and painful.
We're not going to go through that again, so I humbly ask to keep net6 support through multitargeting.
@AristurtleDev cosider this alternative, at least on Desktop packages:
<TargetFrameworks>net6;net8</TargetFrameworks>@vpenades a realistic approach would be legacy applications keeping using 3.8.x + .NET 6 while newer applications would start using 3.9.x + .NET 8. Given that MonoGame releases are like 3 years apart, it makes sense to focus on the future.
I am not sure it would be possible to use the new performance-oriented features otherwise.
@vpenades it wouldnt be much work on my end to change it to multitarget.
@mrhelmut and @harry-cpp thoughts on this?
@dsaf we're not working on a legacy application, there's life outside game development.
We are in charge of developing a large suite of applications for governments and medical corporations, for which we deliver two to three updates a year, and we're expected to do so for the time being.
These updates include new features, bug fixes and so on, so we cannot simply be "stuck" in a 3.8.x version, because in fact, we're still waiting for a new release that fixes the fonts that were broken in the last release.
And we cannot ask our clients to move to net8.0 either, as I've explained in discord:
We work for governments, and our software runs on computers administered by IT departments which have very strict policies about which updates go on each machine. Actually, they usually update all the computers of an adminstration or a department at once.
In fact, many of our clients didn't expect to update to net6 until at least the end of 2024, it took us lots of phone calls to convince them to at least allow us to install net6 runtime (administration machines are usually locked)
This is not only a problem specific to us: Anybody that gets a contract to develop a project for an adminstration, a government or a large corporation, will face this same issue.
Btw, before someone mentions it: Compiling our projects to use AOT or to use an embedded runtime is not an option either because two reasons: our suite is made of many executables, so embedding the runtimes would bump the installation size several GBs (We've tried)... and also for security reasons, a shared runtime allows it to receive security patches.
Question: Is moving from net6 to net8 really required?
I mean, I understand needing to target Net8 because it might add some useful features to consoles/mobile.
What I don't understand is removing support for Net6.
I can't see why it would not be possible to support both frameworks, since it's common practice by most libraries to do multitargeting.
To give some context:
When monogame upgraded to net6 and we adopted it, we had to ask our clients in more than 30 hospitals to install the net6 runtime to support it, and it was unbearably costly and painful.
We're not going to go through that again, so I humbly ask to keep net6 support through multitargeting.
@AristurtleDev cosider this alternative, at least on Desktop packages:
<TargetFrameworks>net6;net8</TargetFrameworks>
Am very curious why u using a game engine in government hospitals environments or was that just a what if scenario
Am very curious why u using a game engine in government hospitals environments or was that just a what if scenario
Real case scenario.
We develop games for brain damage and physical rehabilitation. Right now +100 games for physical rehabilitation, and +200 games for brain damage rehabilitation, and counting.
We're probably the studio that has made more games with MonoGame, ever, (granted, not AAA games), and the only way for you to play them is either coming to our studio, or having a car accident, that's why you don't know about us.
So our biggest issue is that we develop games that need to be deployed on machines administered by hospitals, and are going to be used by real patients, including many kids, so the security is ultra tight, and everything that is going to be installed in these machines needs to be in a white list. It took us months to get the Net6 runtimes to be in these white lists just a year ago.
@mrhelmut and @harry-cpp thoughts on this?
We've had a bit of a discussion about multitargeting, and long story short, its exactly what @dsaf said in his comment, if you need to target an older .NET, you'll need to use an older version of MonoGame.
Any new release of MonoGame will target only the latest LTS .NET as its target.
Any new release of MonoGame will target only the latest LTS .NET as its target.
Well, you would be essentially banning any future releases of MonoGame to be deployable on any corporate/state/government computer.
Given the costs/benefits of supporting both net6 and net8, I don't see why multitargeting is a problem. The advantages are huge for those that require net6, and those that need Net8 would not be hurt by the net6 support, since both Net6 and Net8 are almost identical.
Notice that I am not talking about supporting net6 through the whole ecosystem, only for the packages that are to be deployed along with desktop applications, that is DesktopGL and WindowsDX, which are the only ones affected by runtime security policies.
Well, you would be essentially banning any future releases of MonoGame to be deployable on any corporate/state/government computer.
Well how i read it .NET 6 is in LTS until end of 2024 at the moment... and maybe they extend that.
So i think we're safe for now. Or am i wrong?
So i think we're safe for now. Or am i wrong?
Yes, .Net6 is LTS until the end of 2024 for home users, for enterprise users it's usually extended 1~2 years, because that's about the amount of time enterprise users need to catch up.
What happens in the real world is that enterprise users deploy an update once a year (or two) to all the machines in the organization, this guarantees that all machines look and behave exactly the same. A specific machine is not allowed to have a runtime or a driver or anything that would make that machine different from the other machines in the organization.
That's why you can't simply ask to let you install some runtime in a particular machine. You have to wait an entire year for them to include the runtime in -all the machines-
So by the time the LTS is about to expire for home users, it's when enterprise users are beginning to adopt, That's why Microsoft extends support for enterprise users.
Our everyday's scenario is:
- A client requests our software, we deliver it to them and the client tries to install.
- Net6 is missing, they cannot install the runtime because machine is locked by IT.
- Countless hours explaining the problem to the IT department.
- They plan Net6 for their next year organization wide update.
- We wait between 3 and 10 months until the organization wide update happens.
- we can finally deploy.
So I think, a friendlier policy on MonoGame's behalf would be to support the last two LTS versions, in a staging fashion, to help slow adopters to catch up.
when will this be uploaded to Nuget?
With the next release, tho nothing is stoping you from using the current MonoGame release with .NET 8, this is just for us to be able to use the new .NET features in the library itself.
With the next release, tho nothing is stoping you from using the current MonoGame release with .NET 8, this is just for us to be able to use the new .NET features in the library itself.
the problem is mgcb lagging behind, forcing all content pipeline extensions to target .net 6.
A tighter timeline on just the pipeline tooling version bumps would go a long way towards making MonoGame easy to consume every time a new .net release drops