Set NetRoslyn value for VMR build

[mthalman]

Related to https://github.com/dotnet/installer/pull/18238 and https://github.com/dotnet/roslyn/pull/71507.

There are several projects whose TargetFramework is set to NetRoslyn which is statically set to net8.0. This causes build failures in the context of the VMR because it needs to be targeting net9.0.

These changes update the value of NetRoslyn in the context of building in the VMR so that it will make use of NetCurrent (which will be net9.0 there).

[mthalman]

This section of the TargetFramework.props is for source build and $(NetRoslyn) should not be used in source build. If we find a case where this is blocking source build then our build authoring is incorrect.

Ok, I'll track down which project(s) caused a failure without this patch applied and reply back.

[mthalman]

Here's the build error when this patch isn't applied:

/vmr/.dotnet/sdk/9.0.100-preview.2.24103.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/vmr/src/roslyn/artifacts/obj/Microsoft.CodeAnalysis.Workspaces.MSBuild.BuildHost/project.assets.json' doesn't have a target for 'net8.0'. Ensure that restore has run and that you have included 'net8.0' in the TargetFrameworks for your project. [/vmr/src/roslyn/src/Workspaces/Core/MSBuild.BuildHost/Microsoft.CodeAnalysis.Workspaces.MSBuild.BuildHost.csproj::TargetFramework=net8.0]

From https://github.com/dotnet/installer/pull/18513

cc @jasonmalinowski

[mthalman]

This is still an issue as explained in https://github.com/dotnet/installer/pull/18752#issuecomment-1961585290.

Here's a binlog that demonstrates that net8.0 is being targeted in the VMR by the two projects using the NetRoslyn property: CodeStyleConfigFileGenerator and CSharpSyntaxGenerator. source-inner-build-roslyn.zip

[jaredpar]

This is still an issue as explained in https://github.com/dotnet/installer/pull/18752#issuecomment-1961585290.

As I explained the approach in this PR is not the right way to solve the problem.

[mthalman]

This is still an issue as explained in dotnet/installer#18752 (comment).

As I explained the approach in this PR is not the right way to solve the problem.

Ok, so the build authoring would be incorrect then since these projects are using NetRoslyn in a source build scenario. What is the recommendation here?

[jaredpar]

https://github.com/dotnet/roslyn/pull/72248/files

This is what I envisioned the correct approach to be but it's hitting a source build error 🤦

[mthalman]

Closing in favor of the changes in https://github.com/dotnet/roslyn/pull/72248.