Why does Mapster not uses the LangVersion provided by default from the TargetFrameworks then instead 10.0 / 8.0 ?

[DevTKSS]

(See Title)

I recognized that the new Dictionary.Build.props file does specifiy <LangVersion>10.0</LangVersion> and also quite all Projects doing the same but with 10.0/8.0 even the SourceGenerator netstandard2.0 👀

By the way, I don't think using higher LangVersion is recommended for Source Generator Projects and could potentially result in runtime problems 🤔

Could we maybe check if we still need the LangVersion set explicitily and by that are restrict our Projects to benefit from the Lang features of later versions?

@stagep @DocSvartz @andrerav what do you think?
What were your reasons to use them at all? 🤔 Maybe the Source Generators netstandard2.0 limitation?

I locally curioursly tryed to even centralise them to 10.0 in the Directory.Package.props but then the Mapster Project itself (which does already use 10.0 🤔) did suddenly file that types would not be known and net Core App 3.0 would not support Lang version 10.0 (along with whole bunch of other Projects, but this was the first in the list, which is normally the culprit when some problem results in a rat tail of other problems to fix before something works again)

It looks to me a bit ridiculous, that we are using net8.0;net9.0;net10.0, but keeping the Lang Version Features limited to net6.0 🤔 👎

[DocSvartz]

I locally curioursly tryed to even centralise them to 10.0 in the Directory.Package.props but then the Mapster Project itself (which does already use 10.0 🤔)

If you tried to install LangVersion, it's really weird🤔. Maybe you also changed the TFM?
Currently, all projects use LangVersion 10, except for those that explicitly specify a different version in the project file.

[DevTKSS]

@DocSvartz but the tfm already brings a Langversion appropriate to the tfm... We have 3 tfm and then set the Langversion also. This is redundant 😅
E.g. the tfm regular provided lang Versions:

• net10.0 - 14.0
• net9.0 - 13.0
• net8.0 - 12.0

But we are downgrading to 10.0 / 8.0 C# lang features 😅

Why?

Normally you dont need them, or some are using them to upgrade lang version to e.g. <LangVersion>latest</LangVersion> but very rarely downgrading, thats why I am asking😅

Because in fact, where I would normally not use the LangVersion 10.0 like we are doing is exactly the Source Generators Projects with their TFM of netstandard2.0 and then using the LangVersion of net6.0 is potentially critical issue source!

[DocSvartz]

According to the documentation, this shouldn't work at all, but if you really remove the language version in the build prop, Visual Studio will first offer to update the LangVersion in Mapster.Core to 8 and then to 9. 😅

[DevTKSS]

According to the documentation, this shouldn't work at all,

@DocSvartz so you get my point, why I am asking you and the others ;) Downgrading is the one thing, possible, while not what I would assume to be commonly done when the Package produced only shows >= net8.0 😅

but if you really remove the language version in the build prop, Visual Studio will first offer to update the LangVersion in Mapster.Core to 8 and then to 9.

I think I tryed it in vs code, not sure if I used VS directly, but none of both did suggest something about the LangVersion to me 🤔
But what I did remark was that all of the Projects are having that additional semicolon after the target identifyers:

    <TargetFrameworks>net10.0;net9.0;net8.0;</TargetFrameworks>

so I tryed removing this, but not solved the strange error I mentioned.
Normally I would also expect the Directory.Build.props to add properties defined in there if no condition is specified or the Condition applyes to this project 🤔 but as soon as I "just" removed the LangVersion from the Projects which was eitherway just specifiyng the 10.0 like in this Global File this error occourred.