Fix sdk resolver for net6 assemblies. Using offical .NET release JSON to get runtime version #2625
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…N to get matching runtime version
yazeedobaid
force-pushed
the
fix-sdk-resolver-for-net6
branch
from
aef20fc to
00d4de6
Compare
CumpsD
reviewed
Nov 16, 2021
TheAngryByrd
approved these changes
Dec 3, 2021
edro
approved these changes
Dec 15, 2021
yazeedobaid
added a commit
that referenced
this pull request
Jan 6, 2022
* next release * Fix sdk resolver for net6 assemblies. Using offical .NET release JSON to get runtime version (#2625) * Fix sdk resolver for net6 assemblies. Using official .NET release JSON to get matching runtime version * Update RELEASE_NOTES.md
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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)unit or integration test exists (or short reasoning why it doesn't make sense)
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)Fake 5 API guideline is honored