Added explicit .NET 6 TFMs.

[AraHaan]

Fixes #28477.
Fixes #28492.
Fixes #28577.

Prerequisites:

• Fix compile error when Azure SDK is targeting .NET 6. autorest.csharp#2245

[ghost]

Thank you for your contribution @AraHaan! We will review the pull request and get back to you soon.

[jsquire]

Thank you for your contribution and for helping to improve the Azure SDK experience. Though this is still in draft form, there were a couple of things that caught my eye that I wanted to mention, and one request that I had for the overall pattern.

Please consider moving the conditionals to a new item group with the condition applied there. An explanation of why we're conditionalizing would also be appreciated.

Example:

<ItemGroup>
  <PackageReference Include="Azure.Core" />
</ItemGroup>

<!-- These packages are included as part net6.0; the external references are not needed. -->
<ItemGroup Condition="'$(TargetFramework)' != 'net6.0'">
  <PackageReference Include="Microsoft.Bcl.AsyncInterfaces" />
  <PackageReference Include="System.Text.Json" />
</ItemGroup>

[AraHaan]

I feel like I might need to look into why the merge conflicts are present and if possible resolve them.

[thompson-tomo]

Merging main was painless. So I have done it via: AraHaan#504

[thompson-tomo]

For consistency I feel these should be in an item group rather than directly on the reference.

[thompson-tomo]

For consistency I feel these should be in an item group rather than directly on the reference.

[thompson-tomo]

For maintainability should this be inverted so that adding future frameworks doesn't need the conditions to be touched?

[thompson-tomo]

For maintainability should this be inverted so that adding future frameworks doesn't need the conditions to be touched?

[thompson-tomo]

For maintainability should this be inverted so that adding future frameworks doesn't need the conditions to be touched?

[thompson-tomo]

For maintainability should this be inverted so that adding future frameworks doesn't need the conditions to be touched?

[thompson-tomo]

For maintainability should this be inverted so that adding future frameworks doesn't need the conditions to be touched?

[thompson-tomo]

For maintainability should this be inverted so that adding future frameworks doesn't need the conditions to be touched?

[thompson-tomo]

Should these be merged into 1 condition.

[thompson-tomo]

Is this version override needed?

[AraHaan]

I will need to check once more yeah.

[lahma]

Added a comment about better way to check target platform that will work with newer NET versions too.

[lahma]

It would be better to use Condition="!$([MSBuild]::IsTargetFrameworkCompatible($(TargetFramework), 'net6.0'))" for all such conditions, compatibility check is future-proof

[AraHaan]

That is true, alright I will do it when I can.

[AraHaan]

The issue that was open for this was automatically closed and locked so it could not be reopened by myself. Someone might have to manually reopen it that can do such.

[github-actions]

Hi @AraHaan. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[AraHaan]

This is still a wip.

[github-actions]

Hi @AraHaan. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[AraHaan]

This is still a wip.

[github-actions]

Hi @AraHaan. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[thompson-tomo]

We are still awaiting a review

[jsquire]

Apologies for the long delay here; this turned out to be an issue with many more differing opinions than expected and required a good amount of internal discussion. From the feedback that was shared here and by other community members, we've formalized a plan for multitargeting going forward where we will always have an explicit target for the latest LTS. The working draft of this plan is:

• All clients will target netstandard2.0 and latest LTS
• Core libraries will target netstandard2.0 and latest LTS
• We will remove LTS targets from both client and Core libraries six months after their End of Support date
• We will have a goal to add the latest LTS target when it is released.
• We strongly want to add an LTS target before the end of support date for an older LTS
• We may choose to skip an LTS if there is a compelling reason to do so
• We may choose to add a target for an STS is there is a compelling reason to do so

With the pending end-of-life for net6.0, we're in the process of adding a net8.0 target, setting up central infrastructure to trim package dependencies known to be included in the runtime for modern targets, and bumping dependency versions to the 8.x line. This workstream is tracked by Tracking .NET 8 and 9 updates (#46639). I think we can let this close out if the bot tags it again.