Drop netcoreapp3.1, add net7.0 support

[heaths]

Resolves #32596. With netcoreapp3.1 falling out of support soon, we're upgrading to net7.0, net6.0, and, on Windows, net461.

[heaths]

Builds all of a sudden fail with:

##[error]/mnt/vss/_work/1/.nuget/packages/microsoft.build.tasks.git/1.1.1/build/Microsoft.Build.Tasks.Git.targets(25,5): Error : Error reading git repository information: Unsupported repository version 1. Only versions up to 0 are supported.
/mnt/vss/_work/1/.nuget/packages/microsoft.build.tasks.git/1.1.1/build/Microsoft.Build.Tasks.Git.targets(25,5): error : Error reading git repository information: Unsupported repository version 1. Only versions up to 0 are supported. [/mnt/vss/_work/1/s/sdk/advisor/Azure.ResourceManager.Advisor/src/Azure.ResourceManager.Advisor.csproj::TargetFramework=netstandard2.0]
##[warning]/mnt/vss/_work/1/.nuget/packages/microsoft.build.tasks.git/1.1.1/build/Microsoft.Build.Tasks.Git.targets(25,5): Warning : Unable to locate repository with working directory that contains directory '/mnt/vss/_work/1/s/sdk/advisor/Azure.ResourceManager.Advisor/src'.

Seems to be related to dotnet/sourcelink#772, but why trigger only under net7.0? @ericstj @clairernovotny have you ever seen this before? Could it have anything to do with what versions we install: https://github.com/Azure/azure-sdk-for-net/pull/32814/files#diff-0ee9c9427a1837c466fe62f326ca452d7b3cd1d17f44a859470b2b7fc104754a ?

[heaths]

If I downgrade global.json and our RequiredTargetFrameworks to just "net6.0" (drop "net7.0"), Microsoft.Build.Traversal works correctly. Under net7.0,

1. It doesn't pass the -bl switch to inner builds.
2. It's not passing other properties because it's discovering all track 2 packages to restore and build.
3. Given that, it must clearly not be passing EnableSourceLink=true to inner builds. Hard to say for sure since I can't get a decent log.

[ericstj]

I found the error comes from here:
https://github.com/dotnet/sourcelink/blob/48e002e14a97800c0d6acf24a55357699c9d72a4/src/Microsoft.Build.Tasks.Git/GitDataReader/GitRepository.cs#L121-L125

Just a brief look at where repositoryformatversion comes from, it seems to come from .git/config file, so might be specific to what version of GIT you use to clone the repo and that might be disagreeing with what version of microsoft.build.tasks.git package you are using. That's the only lead I have. @tmat might have some better ideas.

[heaths]

@ericstj, thanks, but that's only a manifestation of the actual problem: microsoft/MSBuildSdks#412

We've been using sparse checkouts for a while but were passing /p:EnableSourceLink=false wherever we did and had no issues. Seems under net7.0, Microsoft.Build.Traversal is not passing properties (or loggers, however that works) to inner builds when calling dotnet test (dotnet build works as it did before). It's being looked into.

[heaths]

@rainersigwald found this was caused by microsoft/vstest#4014

[jsquire]

Changes themselves look good to me.

[heaths]

Per offline discussion, we're going to wait until microsoft/vstest#4014 is released.

[dw511214992]

Hi @heaths This PR breaks the command dotnet new azsdkdpg --name Azure.XXX.Contosoz --clientName Contosoz --groupName XXX --serviceDirectory contoso --force to generate a valid template. For example, there is a generated file named Azure.XXX..csproj with two dots. It blocks all sdk automation pipeline for cadl. I think we need a fix in the tool dotnet new azsdkdpg.

I have created an issue to track it: #33515