Allow locating prerelease versions of the SDK

[YuliiaKovalova]

Add an option in locator to allow for locating prerelease versions of the SDK, not just releases.

[baronfel]

This would be necessary to unblock tooling like tintoy/msbuild-project-tools-server (https://github.com/tintoy/msbuild-project-tools-vscode/issues/144) so that they can seamlessly run on .NET 9 previews. I expect that DevKit would also need this functionality (cc @lifenglu). I know in Ionide, this functionality not being available is one of the reasons we basically reimplemented Locator without this limitation. Essentially, we should do this so that the cottage industry of hacks/workarounds becomes obsolete and we can ensure that folks are locating MSBuild uniformly.

[YuliiaKovalova]

It looks like the recent changes https://github.com/microsoft/MSBuildLocator/blob/b11c59b10c298949f1bdb72c47b46ffd8428ca62/src/MSBuildLocator/MSBuildLocator.cs#L52 satisfy the requested need.

@baronfel and @lifengl please let me know when you verify it.

[lifengl]

Actually, i can always resolve a preview version of the SDK with the existing package (without setting anything).

The key issue is that I need load the process which calls into the package with the preview version of runtime matching the SDK.

This is done by ensuring two things: 1, the process need RollForward to new version of runtime 2, environment variable DOTNET_ROLL_FORWARD_TO_PRERELEASE=1 when I started the process

also, if it will eventually run design time build: 1, the executable need be hosted in dotnet.exe, instead of a self-host application. NET 6 SDK will fail to run out of proc DT build otherwise. 2, run DT build out of process (disable in-proc build). Some customized tasks may crash the process.

[baronfel]

Yes, but that requires you to modify your host process significantly. This API change should allow consumers to be more purposeful about which versions of the SDK they try to locate.

[lifengl]

I am not sure what an API inside the assembly can do. If your process is loaded with NET 8 runtime, instead of using preview version of NET 9 runtime, this package might allow MSBuild in NET 9 SDK to be loaded (well until they are built to target NET 9 runtime later, which happens sooner or later), but you will soon run into failures, because things in the NET 9 preview SDK would not run in the older runtime (likely the workload resolver, or maybe a task). You will have to start the process with the later runtime, when calling this package, it is way too late.

[YuliiaKovalova]

I am not sure what an API inside the assembly can do. If your process is loaded with NET 8 runtime, instead of using preview version of NET 9 runtime, this package might allow MSBuild in NET 9 SDK to be loaded (well until they are built to target NET 9 runtime later, which happens sooner or later), but you will soon run into failures, because things in the NET 9 preview SDK would not run in the older runtime (likely the workload resolver, or maybe a task). You will have to start the process with the later runtime, when calling this package, it is way too late.

We tried to notify the customer that loading preview things isn't safe: https://github.com/microsoft/MSBuildLocator/blob/b11c59b10c298949f1bdb72c47b46ffd8428ca62/src/MSBuildLocator/MSBuildLocator.cs#L47

[baronfel]

@YuliiaKovalova I can confirm that the new flag allows me to detect what I'm looking for - when I'm running in a lower SDK but the user has requested a newer SDK, I can detect that and give them the option of allowing my app to restart in roll-forward mode.

[lifengl]

yeah, that is indeed a valid usage, and it makes sense. Thank you for the explanation.

@YuliiaKovalova I can confirm that the new flag allows me to detect what I'm looking for - when I'm running in a lower SDK but the user has requested a newer SDK, I can detect that and give them the option of allowing my app to restart in roll-forward mode.

[YuliiaKovalova]

Thank you both for checking it! I close the ticket.