Consider adding Roll Forward policy for dotnet-script tool

[GlebChili]

Overview

We are using your amazing tool for our project's CI. Recently we tried to move our project to a preview builds of .NET 6. Since dotnet-script tool is not targeting .NET 6 (yet), it introduced several difficulties to the build pipeline. At first we decided to install both .NET 6 and .NET 5 SDKs to our CI runners. It obviously worked, but made infrastructure harder to maintain. Thus we decided make use of dotnet runtime roll forward feature. We are forcing dotnet-script tool to run on .NET 6 runtime by setting DOTNET_ROLL_FORWARD environment variable to Major. Here is how it works for us: https://github.com/GmodNET/GmodDotNet/blob/68397c31679e68fd3c33671d25294bc6a0dd6236/.github/workflows/ci.yml#L347-L352

This made me think that it can be beneficial for the project to enable roll forward policy by default. It can allow scenarios where tool is used with preview versions of .NET SDK before official targeting for a new runtime is released.

Possible solution

Enabling roll forward policy for dotnet-script tool by default by adding <RollForward>Major</RollForward> property to Dotnet.Script.csproj.

Useful links

Discussion about roll forward for .NET tools: dotnet/sdk#10375 (comment)

Information about roll forward: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#major-version-runtime-roll-forward

[filipw]

Thank you, we will soon multi-target .NET 6 which should resolve it. The reason why we didn't set roll forward in the past was that the dependency model handle in .NET SDK was incompatible (breaking changes) between .NET Core 3.1 and .NET 5 anyway which in that case would have not helped us anyway.

[GlebChili]

Oh, I didn't know that changes could be so dramatic. Then, I guess, issue is closed. I hope you will be able to deliver early support for future .NET releases like .NET 7 as soon as they are available.