Skip to content

Conversation

@dsplaisted
Copy link
Member

This is a rebase and continuation of #51446, which responded to general dotnetup code review feedback from #50988.

Subsequently, I've addressed some of my own code review feedback from the previous PR.

nagilson and others added 15 commits November 10, 2025 16:09
Splits up `ReleaseManifest` into 3 pieces:
- A. Downloading of .NET Archives
- B. Accessing the release manifest & release manifest data structures
- C. Parsing a 'channel' into a ReleaseVersion

This is a better separation of responsibility and makes each class a far more reasonable size.

# Conflicts:
#	src/Installer/Microsoft.Dotnet.Installation/Internal/ArchiveDotnetExtractor.cs
#	src/Installer/Microsoft.Dotnet.Installation/Internal/ReleaseManifest.cs
#	src/Installer/dnup/Commands/Sdk/Install/SdkInstallCommand.cs
What we were doing was setting the AppContext data such that the HOSTFXR_PATH pointed to the installed root location. We don't need to do that, the hostfxr interop(ped) API already points to the dotnet root location within which we want to resolve the hostfxr.
verification should happen in the downloader which will probably be deferred to the release deployment library
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants