Update net7.0 TFM references to net8.0

[MichaelSimons]

In order to be source-build compliant for the .NET 8.0 release. All projects targeting a net7.0 TFM must be upgraded to net8.0. It is preferred that a new NetCurrent Arcade property be utilized as it eliminates this type of maintenance work for every release.

[rainersigwald]

So, this'll be fun. Can NetCurrent be backported to a version of Arcade that we can adopt without requiring .NET SDK 8 preview releases, letting it toggle between net7 for normal operation and net8 for 8 sourcebuild? We don't want to be on an alpha SDK to ship (for example) 17.6 LTS bits.

[MichaelSimons]

@mmitche - Can you respond to @rainersigwald's question?

[mmitche]

I had typed out a big response and then I figured out what you were saying. The key bit here is that the arcade in use is overridden in product source build. So if we backported the properties and msbuild references NetCurrent, then the behavior looks like the following:

Branch	Official build	Repo-level source build	Product source build
17.4 (7.0.100)	net6	net6	net7
17.5 (7.0.200)	net6	net6	net7
17.6 (8.0.100/7.0.300)	net6	net6	net8

It's subtle because the TFM will flip automatically based on the use of the newer arcade in product level source-build.

@MichaelSimons How does repo-level source build determine what SDK to use? Is it just what is in global.json? If that's the case, then there is no way for msbuild to target net8 in source build unless they don't test it in repo-level source build.

[MichaelSimons]

@MichaelSimons How does repo-level source build determine what SDK to use

It uses what is defined in the repo's global.json. Another scenarios in which conditions in the global.json file would be handy.

[MichaelSimons]

Friendly ping to check on the status of this? What can we expect msbuild to target net8.0 at least for source-build?

[rainersigwald]

I'm still unclear on whether Arcade can do this for us. We still target .NET 7 and adopting .NET SDK 8 in this repo would break an awful lot of our tests that depend on the other parts of the SDK to provide a test environment.

[MichaelSimons]

I'm still unclear on whether Arcade can do this for us. We still target .NET 7 and adopting .NET SDK 8 in this repo would break an awful lot of our tests that depend on the other parts of the SDK to provide a test environment.

Is Matt's suggestion of utilizing NetCurrent (or a variant of it) an option? Else is multi targeting an option?

[rainersigwald]

Else is multi targeting an option?

Being required to use the .NET 8 SDK for our .NET 7 and .NET Framework builds is the painful part, and would be necessary to multitarget to .NET 8.

[rainersigwald]

And my question from earlier was: is $(NetCurrent) available to us on our current LTS Arcade?

[MichaelSimons]

And my question from earlier was: is $(NetCurrent) available to us on our current LTS Arcade?

Yes, @mmitche backported to both net7.0 and net6.0 arcade. Specially the LTS PR was dotnet/arcade#12633

[rainersigwald]

Ah, great! Then we can take a look at adopting it soon.

[MichaelSimons]

@rainersigwald - I see you labeled this with Iteration:2023June. Will this make the Preview 6 code complete date (June 21)?

[rainersigwald]

@donJoseLuis gets final say but I hope so :)