.NET 6 End of Support

[nkh0472]

The latest version of mpv.net depends on .NET Core 6.0, which will reach end of support on November 12, 2024. Please consider upgrading to .NET 8 before the end of support date :]

[stax76]

This would mean dropping support for Windows 7, which would be a disappointment for Windows 7 users.

[Andarwinux]

Just drop Windows 7 support, mpv has dropped Windows 7 support. Since they are stuck with the old OS, there is no need for new software and no right to ask for support for it, continuing to make compromises for these selfish bigots only hurts everyone else.

[nkh0472]

This would mean dropping support for Windows 7, which would be a disappointment for Windows 7 users.

While discontinuing Windows 7 support might disappoint its users, it doesn't render mpv.net unusable; they'll just miss out on updates. Similar to Office 2021 and Chrome 109, this move aligns with broader trends.

The real issue lies with .NET ending support for Windows 7. If .NET 6's end of support hasn't impacted your further coding significantly, then perhaps the end of support for Windows 7 isn't a major concern for users who prioritize stability over new features.

PS: even some libmpv build drop the support of win 7

[Andarwinux]

https://github.com/mpv-player/mpv/commit/ab3d0b73f799bfaaa018a3350a246a11c6a52feb

mpv has completely dropped Windows 7 support, it won't run on Windows 7 anyway, it's pointless for mpvnet to retain Windows 7 support.

[fiso64]

@Andarwinux It's possible to run mpv on win7 as discussed in other threads. It's always a tradeoff between compatibility and new features, and new features may not always be that important, even if shiny. Have you personally built a net 8 version of mpv.net to confirm that it is 10 times faster, or why do you think that it's imperative to upgrade?

[nkh0472]

New features may not always be that important

If those Windows 7 users have already decided to use the OLD VERSION (whether it's mpv or any other software), why should we still provide updates for them? The current version is sufficient for their needs, just like Chrome 109 was.

From any angle, mpv won't be the most crucial software among those that have stopped support.

Why do you think that it's imperative to upgrade?

You should ask the people who INVENTED the concept of "end of support." LOL.

Just look at Google (Chrome stopped supporting Windows 7 in April 2023 and XP in March 2016), Microsoft (Windows 7 in January 2020 and XP in April 2014), and Adobe (Photoshop for Windows 7 in 2019 and for XP in 2012). Do you think you can do better than them?

The cost of using an unsupported version isn't just about ignoring Microsoft's warnings every time you compile. Are you responsible for users affected by unfixed security vulnerability and performance issue?

You might say ".NET Core is not my project; why am I responsible for users using an older .NET with security risks?" You are making all users, not noly the developers, bear the cost of those who refuse to use the updated version.

If you want to backport .NET Core's bug fixes, be my guest.

The cessation of support for .Net is not an individual action, but the result of the entire .Net developer community's choices to maintain the normal development of technology.

That is exactly why people should use supported versions. I'm not advocating for the latest, most fancy version, but at least a currently supported one.

[fiso64]

Do you think you can do better than them?

The reason why they have discontinued support is because otherwise they'd have to exert too much effort while trying to support old operating systems and dealing with bugs, to the point where they can't focus on improving their software anymore. Correct me if I'm wrong, but I don't see this happening here. If stax76 has no problem with the number of win7-related issues, or if the application is not likely to produce such problems, why push him to update? "Security" is mostly a bogeyman, while "performance issues" are sometimes real on a case-by-case basis, which is why I asked if there was any evidence that this project would benefit from upgrading. Not every project needs to obsessively follow the community's choices. You can also just upgrade once there is a genuine problem fixed by the newer versions, so why the rush?

[Andarwinux]

and new features may not always be that important

Then you don't need a new mpvnet either, just use the current version.

It's possible to run mpv on win7 as discussed in other threads.

Not sure what you're talking about, the WinRT API will never work on Windows 7.

why do you think that it's imperative to upgrade?

Why do you think not upgrade is imperative? Just give up all new features and fixes for a very few Windows 7 users?

The reason why they have discontinued support is because otherwise they'd have to exert too much effort while trying to support old operating systems and dealing with bugs, to the point where they can't focus on improving their software anymore. Correct me if I'm wrong, but I don't see this happening here.

This is already happened in upstream, just check mpv for recent commits and PRs.

if there was any evidence that this project would benefit from upgrading

https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/

[fiso64]

Not sure what you're talking about, the WinRT API will never work on Windows 7.

You can use an older build of mpv. Some users also mentioned api extensions for windows 7 that can be installed to make it work.

This is already happened in upstream, just check mpv for recent commits and PRs.

We're talking about mpv.net here, no? mpv requires active work to keep supporting windows 7, whereas here so far it seems to be just "don't needlessly upgrade".

https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/

Again, have you personally confirmed that it makes a difference in the case of mpv.net? It sounds amazing until you find out that the bottleneck is somewhere else (although honestly, I've never had any issues with mpv.net being slow). And if it's so great, then why upgrade only now and not sooner? I just think it's a bit silly to upgrade for no reason. If there's a big issue in mpv.net that would be fixed by net8 or if it will substantially improve in some other way, then sure. But just because it reached end of support?

[9ao9ai9ar]

@fiso64 If this is really how you think, you should question the author of mpv.net why he introduced the .NET 5+ Runtime dependency in version 7 that resulted in a lot of things being removed because of compatibility problems with the .NET 6 platform. Afterall, if it ain't broke, why fix it? I won't mind if he'd stuck to .NET Framework 4.8 because it'll be supported for as long as the latest versions of Windows are supported.

I cannot understand why an average household user would ever want to continue using Windows 7. There is Windows 10 which is not as shit as Windows 11 and every alternating versions before it: it has the features of EMET builtin, an aesthetic, responsive and almost unified UI, support for unicode and long paths in the Win32 API, etc. If you have no qualms of using an outdated version of a software, you have no qualms of using an outdated version of a software. Download the last version of mpv.net that still supports Windows 7 and move on. Go use ReactOS or something if you're so retro or anti-recent-Microsoft-spying, if those are your reasons for sticking with Windows 7.

I agree with @stax76 for labeling this issue as priority medium. He's got his priorities right: it is not as urgent and showstopping as the ones labeled priority high, but is not as frivolous as the ones labeled priority low either, because upgrading a crucial, soon-to-be end-of-life dependency is by itself a reasonable request. Your petition (?) for mpv.net to remain on .NET 6 Runtime without further proof that an upgrade will bring about a "10 times performance improvement" is not.

[fiso64]

@9ao9ai9ar

you should question the author of mpv.net why he introduced the .NET 5+ Runtime dependency in version 7 that resulted in a lot of things being removed because of compatibility problems with the .NET 6 platform.

The removal of the command palette in particular is a huge shame as the suggested alternatives aren't as good. Nevertheless I had to update as the newer versions also introduced some important bugfixes. So while I consider the 7.0 update to be an overall net positive (heh) I still would've preferred if the switch to net6 as a requirement hadn't been done so that we'd be able to enjoy the now-removed features as well as the bug fixes. Yes, I think that the 'if it ain't broke, don't fix it' mindset is usually a good one. The "10x performance increase" is an example - I'm really just trying to understand whether it would give a tangible improvement for mpv.net. I'm not too excited about the prospect of losing even more features.

[9ao9ai9ar]

@fiso64

Nevertheless I had to update as the newer versions also introduced some important bugfixes. So while I consider the 7.0 update to be an overall net positive (heh) I still would've preferred if the switch to net6 as a requirement hadn't been done so that we'd be able to enjoy the now-removed features as well as the bug fixes. Yes, I think that the 'if it ain't broke, don't fix it' mindset is usually a good one.

Sadly, this is the reality of most software releases nowadays, and it is explicitly part of Microsoft's culture/strategies to consciously create those "churns" in the name of innovation or advancement. Unfortunately for mpv.net, the project is born out of Windows as a development platform, and .NET in particular as a software stack, so the "churns" will be coming at a rate that is probably only eclipsed by those in the JavaScript ecosystem (and maybe the Python ecosystem also).

On the brighter side, newer .NET releases do sometimes bring about substantial improvements, as is the case for .NET 8.

[nkh0472]

New features may not always be that important

If those Windows 7 users have already decided to use the OLD VERSION (whether it's mpv or any other software), why should we still provide updates for them? The current version is sufficient for their needs, just like Chrome 109 was.

If you have no qualms of using an outdated version of a software, you have no qualms of using an outdated version of a software. Download the last version of mpv.net that still supports Windows 7 and move on.

Given that Windows 7 users have made the decision not to upgrade their operating system or the runtime, this speaks volumes about their preferences. Even if mpv discontinues support for Windows 7, I don’t see a compelling reason to continue supporting it ourselves.

For the tech-savvy users who can find a way to make mpv still run on Windows 7—whether by installing API extensions or using someone else's private builds of libmpv—I believe they fully understand the implications and costs involved. Finding a software that drops support for their system won't be the biggest issue they face, and it certainly won't be news to them, as this scenario has likely occurred many times before in past many years. If they're skilled enough, they can even create a custom build tailored for Windows 7.

However, for the average Windows 7 user, the best approach is simply to use the last supported version. Or, if they truly need a specific new feature of a media player (it's unlikely that only one new feature in one software is what they're after), they might consider upgrading their operating system as a more viable solution.

From any angle, mpv nor mpv.net won't be the most crucial software among those that have stopped support.

---

Yes, I think that the 'if it ain't broke, don't fix it' mindset is usually a good one.

Let's set aside the question of how to define "broke" for a moment. The reason you might choose to use Windows 7 instead of DOS or 98 isn't solely because something broke on those earlier systems, right? If not for using some new software after the XP era, why would something break on XP? The same principle applies here.

---

I understand that migrating can be a tedious task, and if upgrading the runtime doesn’t offer significant improvements for this project, that could justify the developers’ reluctance to adopt .NET 8. After all, the effort required falls on the developers. If they decide not to waste their time on what they perceive as "meaningless" coding that doesn't bring any new features or address urgent bugs, I fully support their decision.

But at this point, is there really a need to keep discussing support for Windows 7?

[stax76]

Microsoft releases a new .NET version every year in December I think, v9 will be released soon, when it's out v6 will be 3 years behind, which isn't terribly long. I probably wait one more year and then update to v8.

[vvyoko]

.NET 7 introduces LibraryImport It is used to replace DllImport mpv.net mainly interacts with libmpv.dll It may improve performance

I have already tried upgrading to .Net 8 It is very easy In Visual Studio Upgrade the program's version to 8 Operations according to IntelliSense prompts can automatically use new features For example: Press alt+enter on the DllImport method and then switch to LibraryImport

The whole process takes less than 10 minutes.

In most cases, there won't be any issues, some functions may have differences in the AW version Prefer using the W version (unicode)

There seems to be some issues with MediaInfo.dll, but since I need to follow the version of mpv.net, I haven't spent much effort resolving it.

[9ao9ai9ar]

@vvyoko Do you mean there are some issues with the current version of MediaInfo.dll in use by mpv.net, and updating dependencies might resolve the issues?

It'd be great if you could submit a pull request.

[vvyoko]

@9ao9ai9ar

At that time, it was a batch operation, and it didn't necessarily mean there was an issue with MediaInfo.dll.

Without changing any code, you can directly upgrade to .NET 8. It's not as complicated as upgrading from .NET Framework to .NET.

It has almost no drawbacks (ordinary users might need to install new runtimes?), and you can enjoy the performance improvements (if any) brought by the new version of .NET. After all, every new release of .NET always touts performance improvements.

[Andarwinux]

Not sure if native AOT is fully compatible with mpvnet, which should avoid the runtime.

[lyndsay9968]

Microsoft releases a new .NET version every year in December I think, v9 will be released soon, when it's out v6 will be 3 years behind, which isn't terribly long. I probably wait one more year and then update to v8.

Exposing users to the danger of using an outdated runtime to satisfy 3% of users of a system whose support ended almost 5 years ago does not sound like a good idea. Although I personally think it is very right to support an already outdated system, this is where I think we should draw the line. E.g. windows 10 should be supported for a very long time, because although it will not be supported from the end of 2025, some versions will receive security patches even until 2032. This is not the case with Windows 7. No version of it is supported with security patches and it is impossible to buy such support (which is possible with Windows 10). I believe that the desire to please the margin that has already accepted life with unsupported software at the expense of the vast majority is the wrong decision. Especially since this puts them at security risk, as media files are a very common attack vector for known vulnerabilities in unsupported software. Please reconsider your decision.

[9ao9ai9ar]

@lyndsay9968 @fiso64 @stax76 Apologies for the multiple pings, but may I suggest a middle ground: provide a build for .NET 6 and another build for .NET 8. According to @vvyoko,

Without changing any code, you can directly upgrade to .NET 8.

which I interpret to mean that only a change in the VS build target settings is required, and DllImport and all the other currently used methods can continue to work on both .NET 6 and .NET 8 runtimes. This grace period will allow users of Windows 10 and later to pilot test mpv.net on .NET 8 runtime for compatibility problems with a fallback version for .NET 6 readily available. A notice about .NET 6 EOL and .NET 8 experimental support should be posted on the releases page on GitHub so that everyone knows what they're getting themselves into by downloading either version. After the .NET 8 version becomes stable enough and stax76 considers the time is ripe, the .NET 6 version is dropped for good.

We also don't spend time now to research native AOT options, as that does not seem to provide a clear net positive for both the devs and the users (less likely to release/get timely security fixes if not managed by Windows Update, and the increased binary size).

If the assumptions turn out to be wrong, that it's not a trivial build config change, then we stop pestering stax76 until the end of next year, the stated tentative date to fully resolve this issue.