F# Scripts: Fix resolving the dotnet host path when an SDK directory is specified

[DedSec256]

The FSharpChecker.GetProjectOptionsFromScript method has an optional parameter sdkDirOverride, which allows specifying the SDK with which the script will be analyzed in the IDE. However, for restoring NuGet packages, this info is not used, which leads to some unpredictable behavior. In some cases, for example, when using a new version of .NET installed in a non-standard location, restoring NuGet packages becomes impossible with an error like

error NETSDK1045: The current .NET SDK does not support targeting .NET 9.0. Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 9.0

This PR fixes this issue, taking into account the sdkDirOverride parameter for NuGet restoring in the default FSharpDependencyManager.

It also improves additional log info in the generated Project.fsproj.fsx, showing the correct path to the used dotnet.exe instead of the outdated hardcoded.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.0.md

[T-Gro]

I get the intention.

But still, I believe future human and non-human coders would appreciate a few comments about what is being done here and especially why.

[T-Gro]

What changes, docs or implementation or some limited guidance perhaps, are to be done towards 3rd party Dependency Providers together with this change?

In this case, the purpose (fixing nuget, the dominant provider) is justified and I think it's OK to expand the possibility of sdkDirOverride to other providers - do I understand it right that now every provider can retrieve this info?

(I am coming from a philosophical question if a direct string param is correct here and if it does not close too many future-expansion points.

After all, the construction logic is driven via constructor overloads and locking down string option as a constructor argument might be kick as back later.

Have you considered ways of making this parameter more semantic, either by changing construction logic or by also utilizing the parameter's name on top of the GetConstructor search perhaps?)

[DedSec256]

@T-Gro

do I understand it right that now every provider can retrieve this info?

Right.

What changes, docs or implementation or some limited guidance perhaps, are to be done towards 3rd party Dependency Providers together with this change?

I've been looking at similar changes with adding the result caching parameter, but I didn't see any docs change there (if don't count the description for an fsi parameter). The readme does not contain additional information about the parameters and simply refers to the default implementation:

The current implementation follows pattern that can be deducted by referring to implementation in DependencyProvider.fs

Nevertheless, paket uses only the outputDir parameter.

Have you considered ways of making this parameter more semantic, either by changing construction logic or by also utilizing the parameter's name on top of the GetConstructor search perhaps?)

The current dependency provider plugin system is based on duck typing and versioning via constructor overloads. The main thing here is the signature of the constructor, and no one is obligated to use the exact names of the parameters; I also do not know if there are third-party implementations that use not strict naming for these parameters.

One of the options I considered was using a public property with a setter:

• It is searched strictly by name.
• It can be initialized independently of any used constructor overload.

Perhaps we could use this approach here.

We can also make everything even more fluid and pass Dictionary<string, object>, which can be as flexible as you want, but I like this idea a lot less.

Do you have better ideas?

[T-Gro]

Thanks @DedSec256 .

Since it is all invoked via reflection anyway, I do not see that much of a difference between properties (which will be authored as strongly-typed, but in practice always set by reflection) and a dictionary property bag.

Right now, the dict approach is the most appealing to me - it could still remain a constructor argument, ensuring propper init. And will not lock any future addition down, as it is easily expandable.