Reverting change to target frameworks that breaks kokoro

[mkruskal-google]

Kokoro tests were broken by 10df21e

[dlj-NaN]

Unfortunately, we don't run aarch64 in presubmit, so I guess we'll see what happens...

@jskeet FYI. I'm not sure if this is the right change, but we did end up seeing errors in the continuous build.

[mkruskal-google]

Yea I noticed that. I took a closer look at the failure though and I'm now fairly confident this is the issue. crosses fingers

[jskeet]

It's somewhat strange if net6.0 works but net60 doesn't... but there's no harm in terms of the testing itself. (Basically they should mean the same thing.)

[mkruskal-google]

@jskeet It was the other way around. "net6.0" produced errors like this in our continuous testing:

/usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1005: Assets file '/work/csharp/src/Google.Protobuf.Test/obj/project.assets.json' doesn't have a target for 'net60'. Ensure that restore has run and that you have included 'net60' in the TargetFrameworks for your project. [/work/csharp/src/Google.Protobuf.Test/Google.Protobuf.Test.csproj]

[jskeet]

Sorry, yes - that's what I meant. Basically I'd expect it to work for both or neither...

[mkruskal-google]

IIUC the issue was only for csharp_aarch64 which runs the tests with dotnet publish ... -f net60 .../Google.Protobuf.Test.csproj. Other architectures use netcoreapp3.1, so they didn't hit this issue. As we mentioned above though, we weren't able to confirm this in github so I'm not 100% sure that was the issue

[jskeet]

Ah, right - so changing the script to use -f net6.0 is probably the more appropriate fix, in the long run. (I think net6.0 is a more "canonical" form of the target framework.)

[mkruskal-google]

Fair enough, I wasn't sure where that was specified so this was the quicker fix. Either way sgtm