Skip to content

Add interfaces for installation library #51184

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 5 commits into
base: dnup
Choose a base branch
from
Open

Add interfaces for installation library #51184

wants to merge 5 commits into from

Conversation

dsplaisted
Copy link
Member

@dsplaisted dsplaisted commented Oct 9, 2025 •
edited
Loading

Initial draft of interfaces to support VS Project System and Aspire scenarios. These are almost certain to change but should let us get feedback and get started.

Primary interfaces

public interface IDotnetInstallDiscoverer
{
    DotnetInstallRoot GetDotnetInstallRootFromPath();

    IEnumerable<ReleaseVersion> GetInstalledVersions(DotnetInstallRoot dotnetRoot, InstallComponent component);
}

public interface IDotnetReleaseInfoProvider
{
    IEnumerable<string> GetAvailableChannels();

    ReleaseVersion GetLatestVersion(InstallComponent component, string channel);

    // Get all versions in a channel - do we have a scenario for this?
    //IEnumerable<ReleaseVersion> GetAllVersions(InstallComponent component, string channel);

    SupportType GetSupportType(InstallComponent component, ReleaseVersion version);
}

public interface IDotnetInstaller
{
    void Install(DotnetInstallRoot dotnetRoot, InstallComponent component, ReleaseVersion version);
    void Uninstall(DotnetInstallRoot dotnetRoot, InstallComponent component, ReleaseVersion version);
}

Support types

public record DotnetInstallRoot(
    string Path,
    InstallArchitecture Architecture);

public enum InstallArchitecture
{
    x86,
    x64,
    arm64
}

public enum InstallComponent
{
    SDK,
    Runtime,
    ASPNETCore,
    WindowsDesktop
}

public enum SupportType
{
    OutOfSupport,
    LongTermSupport,
    StandardTermSupport
}

nagilson
nagilson reviewed Oct 9, 2025
View reviewed changes
Copy link
Member

@nagilson nagilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick up take on this - I've left some feedback below!

src/Installer/Microsoft.Dotnet.Installation/IDotnetInstaller.cs

public interface IDotnetInstaller
{
void Install(DotnetInstallRoot dotnetRoot, InstallComponent component, ReleaseVersion version);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we provide a doc string mentioning this Installer interface does not support updating / tracking of these installers? I imagine we'll end up implementing an 'archive' installer for local zip installs just like how the other one works today. That allows us to expand with an admin installer in the future (msi, pkg, distro feed pk mgr)

src/Installer/Microsoft.Dotnet.Installation/IDotnetInstaller.cs

public interface IDotnetInstaller
{
void Install(DotnetInstallRoot dotnetRoot, InstallComponent component, ReleaseVersion version);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to support a custom interface for our output? (e.g. spectre .console abstraction)
We could do similarly for logging.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious on @MichaelSimons opinion on this!

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 this is something to ask Aspire. Would we also make use of it in the DNUP usage scenario?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, how we want to hook up logging (and in general console output) is a good question.

src/Installer/Microsoft.Dotnet.Installation/IDotnetReleaseInfoProvider.cs

ReleaseVersion GetLatestVersion(InstallComponent component, string channel);

// Get all versions in a channel - do we have a scenario for this?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are using the term channel currently to mean, 'latest' or 'lts' or '9.0' or '9.0.102' in DNUP we may want to consider the terminology here. Channel has a specific meaning the release manifest context which is separate from how we are treating it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does channel mean in the context of the release manifest? Any ideas on how to disambiguate?

Copy link
Member

@nagilson nagilson Oct 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A channel version typically describes the major.minor that defines the manifest: https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/2.1/releases.json ( see at the top of the file.) @joeloff mentioned channel is considered an overloaded term. (Note that I take ownership of calling it a channel too in the code 😁 )

The LTS/STS disambiguation is a term called 'release-type'.

The fully specified version is a 'version'.

So far in our code base, the 'channel' can be any of those - a fully specified version, unfully specified version (or even a channel-version per se), a release type, or something else ('latest', 'preview').

MichaelSimons
MichaelSimons reviewed Oct 9, 2025
View reviewed changes
Copy link
Member

@MichaelSimons MichaelSimons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will the consumer acquire/instantiate the concrete implementations of these interfaces?

src/Installer/Microsoft.Dotnet.Installation/IDotnetInstaller.cs

public interface IDotnetInstaller
{
void Install(DotnetInstallRoot dotnetRoot, InstallComponent component, ReleaseVersion version);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aspire asked for update support. Is the vision that they would manage the update via the install/uninstall apis vs providing a direct api?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Daniel and I discussed and the vision was that there would be a separate installer interface that creates the 'dnup manifest' but just not in a dnup directory and instead in the dotnet root. The first release of the lib would just support basic install and a more complex interface would later be available that does more of the heavy lifting. I think we called it IDotnetInstallerManager.

@dsplaisted
Copy link
Member Author

How will the consumer acquire/instantiate the concrete implementations of these interfaces?

Not sure at this point, we may have concrete classes that can be instantiated, or maybe we'll have a static factory.

@joperezr
Copy link
Member

@davidfowl @DamianEdwards @mitchdenny can you folks take a look at this? The idea would be to use these interfaces as part of our CLI to be able to get a local copy of the SDK.

@davidfowl
Copy link
Member

What is ReleaseVersion? Is it a SemanticVersion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@MichaelSimons MichaelSimons MichaelSimons left review comments

@nagilson nagilson nagilson left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@dsplaisted @joperezr @davidfowl @MichaelSimons @nagilson