Add an option to resolve SDK runtime version from a cache file #2630
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
This PR continues the work done on #2625 which adds functionality to resolve the SDK runtime version for referenced assemblies using the official Dotnet releases package (Microsoft.Deployment.DotNet.Releases). Using this package provides an exact matching runtime version for the specified SDK version from a
global.json
file. However, as raised in the #2618 issue, this solution has the downside of network restrictions or failure.This PR attempt to address the downside by caching the releases file and fallback to it when accessing the network is not an option. The solution is as follows:
CacheDotNetReleases
has been added to FAKE's build script to get the releases file and cache it in the filesrc/app/Fake.Runtime/cachedDotnetSdkReleases.json
SdkAssemblyResolver.fs
will now fallback to that file if the runtime version cannot be resolved from the network for any reason.For the cached file and the updates on it. Dotnet releases are not very frequent. So updates to this release description are not done frequently. If this file got outdated and accessing the network is not an option, the
SdkAssemblyResolver.fs
will fail the script with a descriptive message. For this rare case, the solution would be to publish a new release of FAKE that will update the cached file.Feedback is highly appreciated,
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