Update LangVersion in individual projects

[AlexanderSher]

No description provided.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[pallavit]

Can/should we plan to add an analyzer rule to check for this?

[AlexanderSher]

Can/should we plan to add an analyzer rule to check for this?

@pallavit You mean check that internal projects don't define lang version? From time to time it can be useful, cause new versions of language can introduce breaking changes that we may have no capacity to fix immediately.

[jsquire]

Can/should we plan to add an analyzer rule to check for this?

I don't think so. Individual packages should be able to deviate if needed. Particularly this is useful when you need to back-pin a specific library to work around compiler issues.

[heaths]

Can/should we plan to add an analyzer rule to check for this?

@pallavit You mean check that internal projects don't define lang version? From time to time it can be useful, cause new versions of language can introduce breaking changes that we may have no capacity to fix immediately.

As long as new syntactic language features can be built by the SDK in the root global.json. Language features that require a newer SDK should already fail the build since we target netstandard2.0 at least. We do require public APIs to be the same across TFMs for now, and I have #33433 on my plate to hook up to help ensure that since the .NET team already has a solution for this (as well as backcompat checks - a replacement for what we're using now).