-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Apply dotnetup code review feedback #51711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: release/dnup
Are you sure you want to change the base?
Apply dotnetup code review feedback #51711
Conversation
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
baronfel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some things that jumped out at me as I was checking this out this evening.
| }; | ||
|
|
||
| // Set user-agent to identify dnup in telemetry | ||
| client.DefaultRequestHeaders.UserAgent.ParseAdd("dnup-dotnet-installer"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we should embed library version here, retrieved from the AssemblyInformation attributes.
| /// <param name="progress">Optional progress reporting</param> | ||
| void DownloadArchive(string downloadUrl, string destinationPath, IProgress<DownloadProgress>? progress = null) | ||
| { | ||
| DownloadArchiveAsync(downloadUrl, destinationPath, progress).GetAwaiter().GetResult(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're going to need to unblock all of this async usage. In 2025 we should not be creating libraries that block threads. Do we have a work item to do this already?
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.