Using RuntimeInformation.FrameworkDescription to determine the runtime version seems to be not guaranteed and how it determines the runtime version is not obvious. I tried it with the following installed SDKs and runtimes:
SDK version -> runtime version
6.0.100-preview.3.21202.5 -> 6.0.0-preview.3.21201.46.0.100 -> 6.0.0
Specifying the two SDKs in a global.json file, in both cases, it resolved to 6.0.0-preview.3.21201.4 runtime.
The release index contains DotNet releases, which include released SDKs, runtimes, and all other information. The Microsoft.Deployment.DotNet.Releases package is a typed wrapper around that JSON file.
Credit goes to @baronfel for suggesting it. Thanks
fixes #2618
To test different versions of SDK and how SdkAssemblyResolver resolves them correctly, I had to add an environment variable FAKE_SDK_RESOLVER_CUSTOM_DOTNET_PATH to inject DotNet host installation path. Installing DotNet in GitHub actions resulted in overriding the currently used SDK 6.0.100-preview.3.21202.5 since both are installed in the user directory location. And installing it in another place will not let SdkAssemblyResolver pick it up since it looks at the user and system default installation location for DotNet. Adding multiple SDK installations in GitHub actions will solve the problem, but will make it difficult to use FAKE repository directly, since in that case, FAKE will require multiple SDK installations to exist on the machine, which is not practical.
If anyone has better ways to accomplish this, please let me know.
Thanks
TODO
Feel free to open the PR and ask for help
[ ] New (API-)documentation for new features exist (Note: API-docs are enough, additional docs are in help/markdown)
[x] unit or integration test exists (or short reasoning why it doesn't make sense)
[x] boy scout rule: "leave the code behind in a better state than you found it" (fix warnings, obsolete members or code-style in the places you worked in)
[ ] (if new module) the module has been linked from the "Modules" menu, edit help/templates/template.cshtml, linking to the API-reference is fine.
[ ] (if new module) the module is in the correct namespace
[ ] (if new module) the module is added to Fake.sln (dotnet sln Fake.sln add src/app/Fake.*/Fake.*.fsproj)
Description
Use Microsoft.Deployment.DotNet.Releases which parses Releases Index to determine .NET runtime version matching resolved SDK specified in a
global.jsonfile.Using
RuntimeInformation.FrameworkDescriptionto determine the runtime version seems to be not guaranteed and how it determines the runtime version is not obvious. I tried it with the following installed SDKs and runtimes:SDK version -> runtime version
6.0.100-preview.3.21202.5->6.0.0-preview.3.21201.46.0.100->6.0.0Specifying the two SDKs in a
global.jsonfile, in both cases, it resolved to6.0.0-preview.3.21201.4runtime.The release index contains DotNet releases, which include released SDKs, runtimes, and all other information. The
Microsoft.Deployment.DotNet.Releasespackage is a typed wrapper around that JSON file.Credit goes to @baronfel for suggesting it. Thanks
To test different versions of SDK and how
SdkAssemblyResolverresolves them correctly, I had to add an environment variableFAKE_SDK_RESOLVER_CUSTOM_DOTNET_PATHto inject DotNet host installation path. Installing DotNet in GitHub actions resulted in overriding the currently used SDK6.0.100-preview.3.21202.5since both are installed in the user directory location. And installing it in another place will not letSdkAssemblyResolverpick it up since it looks at the user and system default installation location for DotNet. Adding multiple SDK installations in GitHub actions will solve the problem, but will make it difficult to use FAKE repository directly, since in that case, FAKE will require multiple SDK installations to exist on the machine, which is not practical.If anyone has better ways to accomplish this, please let me know.
Thanks
TODO
Feel free to open the PR and ask for help
[ ] New (API-)documentation for new features exist (Note: API-docs are enough, additional docs are in
help/markdown)[x] unit or integration test exists (or short reasoning why it doesn't make sense)
[x] boy scout rule: "leave the code behind in a better state than you found it" (fix warnings, obsolete members or code-style in the places you worked in)
[ ] (if new module) the module has been linked from the "Modules" menu, edit
help/templates/template.cshtml, linking to the API-reference is fine.[ ] (if new module) the module is in the correct namespace
[ ] (if new module) the module is added to Fake.sln (
dotnet sln Fake.sln add src/app/Fake.*/Fake.*.fsproj)[x] Fake 5 API guideline is honored