Update .NET Version from 5 to 8, and Language Version from 10 to 12

[Captain-Quack]

The current version of .NET that the projects in this repo use, .NET 5, has reached its end of life and is no longer supported. This commit fixes that by upgrading the version to what is currently recommended, .NET 8.

Additionally, this pr bumps the language version from 10 to 12 to take advantage of modern language features.

[danilwhale]

we can use LibraryImport instead of DllImport when we will update
(https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke-source-generation)

[Captain-Quack]

Oops, I'm sorry. I did not mean to merge again.

[thealpaca89]

Hi @Captain-Quack, is there any update on this?

[Captain-Quack]

@chrisdill is this ready to be merged into the main repository?

[9ParsonsB]

Updating the targetFramework put serious limitations on downstream for no reason. Unless there is a compelling case to do so, I don't see why we would do this.

Bumping the Language version is fine as it only requires a newer compiler, not a new runtime.

[chrisdill]

@Captain-Quack I agree with @9ParsonsB on updating the language version. Not sure on the target framework. Could multi target to keep support for downstream projects though unsure if that is worth doing.

[9ParsonsB]

Not against updating the framework, but I would ask: what do we gain by doing this? Because I think the answer will end up being very little

[Captain-Quack]

(Sorry for the long wait) I don't have any strong reason for or against the framework update. This pr was done in the first place to perform a general update, and I totally get the concerns for downstream projects.

[9ParsonsB]

@chrisdill Do we want to move ahead with LanguageVersion change? I see no issue.

Need to update this PR to remove targetFramework change before merging

[chrisdill]

@9ParsonsB Moving ahead with the LanguageVersion change sounds good to me.

[recore67]

I wouldn't see why we'd abstain from updating the framework, considering the risks. Wouldn't .NET 8 provide more external support and future-usability? Just like with what @danilwhale mentioned for LibraryImport. I mean it sounds normal to me have downstream projects left-affected, it happens all the time.

[9ParsonsB]

I wouldn't see why we'd abstain from updating the framework, considering the risks

Because there is no reason to.

Wouldn't .NET 8 provide more external support and future-usability?

We can always change it when it becomes an issue. Right now, it would only be artificially limiting downstream.

like with what @danilwhale mentioned for LibraryImport

We've looked at LibraryImport and may move to it in the future, but we dont have the capacity to change & test everything right now.

This is not a diktat, if there is a reason to make the change, we are happy to do so.
Contributions are welcome.