search

ffmpeginteropx / FFmpegInteropX

FFmpeg decoding library for Windows 10 UWP and WinUI 3 Apps
Apache License 2.0
211 stars 53 forks source link

experimental dotnet 8 support #409

Closed brabebhin closed 8 months ago

brabebhin commented 9 months ago

Experimental .net 8 support. This makes the sample winui work with .net 8.

brabebhin commented 9 months ago

Hi @lukasf, i think we should consider dropping (not really since we never did it officially) support for dotnet 7 and 6. This should eliminate the need to test those versions with winui 3. Eventually most of the existing app users will switch to 8 anyways.

The problem here is twofold: the RID stuff changes the folder structure and also adds some new properties to the project file, but the ffmpeg build nuget layout is also changed. We should plan out the future development on supporting dotnet 8 as part of the nuget package layout for version 2.0.0

Note that this PR references a ffmpeg nuget build that does not exist outside of my PC. It was generated from the updated nuspec file.

softworkz commented 9 months ago

I don't understand this PR. Those are the UWP dlls and there is not .net8 which works with UWP.

Generally speaking, there is no need to drop support for .net < 8, It's sufficient to change the folder names from win10-xxx to win-xxx, which will work with earlier .net versions as well.

brabebhin commented 9 months ago

Generally speaking, there is no need to drop support for .net < 8, It's sufficient to change the folder names from win10-xxx to win-xxx, which will work with earlier .net versions as well.

Hmm interesting. I will try that. I actually tried several folder hacks, the only one that works was this, but I didn't try to have the win-xxx folders in net 6.

softworkz commented 9 months ago

Generally speaking, there is no need to drop support for .net < 8, It's sufficient to change the folder names from win10-xxx to win-xxx, which will work with earlier .net versions as well.

Hmm interesting. I will try that. I actually tried several folder hacks, the only one that works was this, but I didn't try to have the win-xxx folders in net 6.

I think a good idea for the future might be to: Always look at the Win2D project and see how they are adapting their code and their packages (https://github.com/Microsoft/Win2D/).

From all official MS packages, it has the highest similarity to FFmpegInteropX (A history in UWP, low-level native code, WinRT, CppWinRT, CsWinRT, uap10, netcoreX, graphics, Windows.x + Microsoft.x namespaces, WinUI2, WinUI3, WinAppSDK, etc.) It's actively developed and will continue to be (WinUI3 and MAUI depend on it) and required changes will be made just-in-time.

brabebhin commented 9 months ago

Thanks @softworkz for the tip. You are indeed correct, dotnet 6 seems to be "forwards" compatible with dotnet 8 with the win-xXX folders. So we can get rid of the win10-xXX folders.

softworkz commented 9 months ago

win-xxx have always been valid RIDs. I just checked our codebase and our native dll folders are named like that ever since. I think at some time, they needed a distinction for stuff (probably something related to Windows runtime and UWP), which only runs on win10 and not on earlier OS versions. This had become superceded shortly after, by introducing target framework identifiers (like net6.win10.19401.0) which also introduced the concept for downlevel compatibilitiy (MinFrameworkVersion). Those numbers are actually Windows SDK version numbers and the Windows SDK version is tied to the OS version (it's fixed). (Windows SDK includes the Window Runtime)

The problem with that, is that they are unable to bring new features to older OS versions and the checking for feature availability (like the FFmpegInteropX code is doing here in some cases) is tedious.

That's how they came to the WinAppSDK and WinUI3. The big difference here is that newer versions of the WinAppSDK can be shipped with an application, to all (supported) OS versions, and as a developer, you can use a new feature right away instead of saying: "Yea nice, maybe after 2-3 years when a sufficient amount of users are on the new OS version, then we can probably make use of that feature".

So, the idea is good (....at least)..

softworkz commented 9 months ago

(sorry, wrong button)

brabebhin commented 9 months ago

(sorry, wrong button)

No worries, I actually done that myself at some point. I never understood why there's a shortcut with "Close with comment" so readily available in the UI.

softworkz commented 9 months ago

No worries, I actually done that myself at some point. I never understood why there's a shortcut with "Close with comment" so readily available in the UI.

Actually I didn't even click the wrong button. I got myself used to do STRG+ENTER, which allows to submit posts in many UIs without touching the mouse. And the default button action was "Close" (don't know why). So yea, I agree - Close should not be so prominent and neither the default action.