[build] Target net7.0.

[jpobst]

Context: dotnet/android#6598

Update Java.Interop <TargetFrameworks> to use $(DotNetTargetFramework) like XA does. Additionally, bump this value to net7.0.

Much like the previous #986, Mono cannot build with the .NET 7 reference assemblies:

/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets
(1232,5): error MSB3971: The reference assemblies for ".NETFramework,Version=v7.0" were not found. You might be using an 
older .NET SDK to target .NET 5.0 or higher. Update Visual Studio and/or your .NET SDK. 

In order to fix this, the Mac - Mono lane now builds with .NET 7, however the tests are still run with Mono.

Command line utilities will continue to be built with stable net6.0.

Test XA PR to ensure it works with XA: dotnet/android#7028.

[pjcollins]

Waiting for the latest results for dotnet/android#7028, but I think this should be good to go.

[jonathanpeppers]

I made a thing like $(DotNetStableTargetFramework) in xamarin-android for console apps that are used during our build. Should utilities we ship like class-parse actually build against 7? It is invoked from MSBuild in customer projects, but they should have a .NET 7 SDK.

We can also wait and update these later.

[pjcollins]

I figured $(DotNetStableTargetFramework) would also be useful in JI for certain projects, but using it more widely was a bit of a hassle. Keeping the tools that XA ships on a stable .NET version gives us the flexibility to not require a system wide .NET 7 install in XA for now. If we bump these to net7.0 XA will require a global net7.0 install, or we'll need to update our build tasks to run the tool with our local dotnet install. I don't mind bumping these to net7.0 now but I didn't see a strong need to do so, but maybe I am not considering something.

[jpobst]

I'm fine with whatever is easiest for now, but we should endeavor to get everything we ship running on .NET 7 previews since that is how our customers will eventually receive it. We need to find any issues caused by .NET 7 before they do. 😁

[jonathanpeppers]

xamarin-android/main is already running these on .NET 7, they just have a TargetFramework of net6.0.

If you look at a .binlog of one of our MSBuild tests, it's using a local .NET 7 SDK we provision at ./bin/Release/dotnet/dotnet.

These definitely work on 7, because 6 isn't in here at all:

[pjcollins]

I didn't look too closely, but I think the AndroidDotnetToolTask that runs tools like generator and class parse only uses the dotnet that is found in path? In our XA build case where we test out of a "sandboxed" location I think we end running these tools with the latest version installed system wide. We may want to update that task to try to detect and use the dotnet path that the project is being built from, assuming this is the case. I can investigate this further outside of this PR though.

[jonathanpeppers]

I think there must be some logic when you Process.Start("dotnet") from inside a dotnet process, for example dotnet run just does this:

https://github.com/dotnet/sdk/blob/ad1ca90ad286288970a4ae1ec77e85848fef5a24/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L869-L877

[pjcollins]

I'm not quite sure, previous XA PR builds testing these changes had issues running class-parse and other tools because the XA test environments no longer have NET 7 installed system wide. That blob also mentions an old unresolved issue that seems related. I put up dotnet/android#7038 for now, we can discuss this further over there.

I'm going to revert the $(DotNetStableTargetFramework) changes in this PR.

[jonathanpeppers]

Same with this one, should it build for 7?

[jonathanpeppers]

I'm OK to leave some of the projects in here on 6, the only problem would be if we wanted to use a feature of .NET 7? I don't know if the fast, source generator Regex feature, for example, might be useful in generator or class-parse.

[jonpryor]

This "confuses" me, and I'm not sure what's going on. $(DotNetTargetFramework) is net7.0, thus I would expect bin/Debug-net7.0/Xamarin.Android.Tools.Bytecode.dll to be a file that exists after a build.

However, it doesn't exist; instead, I have bin/Debug-net6.0/Xamarin.Android.Tools.Bytecode.dll, which is a copy of the .NET Standard 2.0 build, which is weird.

Meaning, as a consequence of this change, e.g. the net6.0 class-parse.dll now references the .NET Standard 2.0 build of Xamarin.Android.Tools.Bytecode.dll (v0.2.0.11), whereas before this change it referenced the net6.0 build, 7.0.0.7.

In this case that likely doesn't matter, as there's no #if NET in Xamarin.Android.Tools.Bytecode.dll, but if that ever changed…

I suspect what we actually want/need is to instead add a 3rd $(TargetFramework) value in many of these places, instead of replacing net6.0 with net7.0, a'la:

<TargetFrameworks>netstandard2.0;$(DotNetStableTargetFramework);$(DotNetTargetFramework)</TargetFrameworks

[jpobst]

Or this is a good reason to make everything target net7.0 instead of some things still targeting net6.0.

[pjcollins]

I've moved everything back to target net7.0.

[jonpryor]

Context: https://github.com/xamarin/xamarin-android/pull/6598

Update `$(TargetFrameworks)` across the various `.csproj` files to
use `$(DotNetTargetFramework)`, as xamarin/xamarin-android does.
Additionally, set `$(DotNetTargetFramework)`=net7.0 (.NET 7).

Similar to commit e7bacc37, Mono cannot be used to build against
.NET 7 reference assemblies:

	/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(1232,5):
	error MSB3971: The reference assemblies for ".NETFramework,Version=v7.0" were not found.
	You might be using an older .NET SDK to target .NET 5.0 or higher.
	Update Visual Studio and/or your .NET SDK.

Fix this by updating the **Mac - Mono** CI job to *build* with .NET 7,
while Mono-focused unit tests are still run with Mono.

Co-authored-by: Peter Collins <[email protected]>