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
Copy link
Member

@baronfel baronfel left a 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");
Copy link
Member

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();
Copy link
Member

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?

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.

3 participants