Add ActivitySource telemetry to Microsoft.Dotnet.Installation

[Copilot]

Implementation Complete ✅

• Add System.Diagnostics.DiagnosticSource package reference to Microsoft.Dotnet.Installation.csproj
• Create an ActivitySource for the Microsoft.Dotnet.Installer library in a new file
• Add Activity for DotnetInstaller.Install method with tags:
  • install.root (install root path)
  • install.arch (installation architecture)
  • install.component (component being installed)
  • install.version (version being installed)
• Add sub-activities for Prepare and Commit stages in ArchiveDotnetExtractor
• Build and verify the implementation works correctly
• Use assembly version for ActivitySource instead of hardcoded "1.0.0"

Summary

This implementation adds System.Diagnostics.Activities support to enable Aspire and other telemetry tools to collect installation metrics before the SDK's own telemetry is initialized.

Key Changes

1. Created InstallationActivitySource.cs - Contains a static ActivitySource with name "Microsoft.Dotnet.Installer" using the assembly's InformationalVersion

2. Modified DotnetInstaller.Install - Wraps the installation process in an Activity named "DotnetInstaller.Install" with tags for:

   • install.root - The installation path
   • install.arch - The target architecture (x86, x64, arm64)
   • install.component - The component type (SDK, Runtime, etc.)
   • install.version - The version being installed

3. Added sub-activities in ArchiveDotnetExtractor:

   • DotnetInstaller.Prepare - Tracks the download/preparation phase
   • DotnetInstaller.Commit - Tracks the extraction/installation phase

Design Decisions

• ActivitySource lifecycle: The ActivitySource is stored as a static field, which is the recommended pattern. It should live for the application's lifetime and doesn't require disposal.
• Activity version: Uses AssemblyInformationalVersionAttribute to get the version dynamically from the assembly, with "1.0.0" as fallback.
• Activity tags: Used the install.* prefix for tag names to follow OpenTelemetry semantic conventions.
• Sub-activities: Created as child activities within the Prepare/Commit methods to provide granular telemetry.

The implementation is minimal, focused, and follows standard patterns for OpenTelemetry instrumentation in .NET.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Create System.Diagnostic.Activities for early data collection</issue_title>
<issue_description>This will enable Aspire to report telemetry for us prior to our own telemetry being lit up.

We'll want to

• create an ActivitySource for the Microsoft.Dotnet.Installer library
• create an Activity for the DotnetInstaller.Install method, adding tags for
  • install root
  • install arch
  • component
  • version
• Have sub-activity for the prepare and commit stages</issue_description>

<agent_instructions>Make sure to only change the Microsoft.Dotnet.Installation project</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Create System.Diagnostic.Activities for early data collection #51578

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[baronfel]

@copilot can you get the version of the MIcrosoft.Dotnet.Installation dll from assembly attributes and use it here in stead of 1.0.0?

[Copilot]

Done in f92fa73. The ActivitySource now uses AssemblyInformationalVersionAttribute to get the version from the Microsoft.Dotnet.Installation assembly, with "1.0.0" as a fallback.

[nagilson]

Should we be using a try-catch pattern to log exceptions which are thrown? I don't know if that's done automatically.

catch (Exception ex)
{
    activity?.SetStatus(ActivityStatusCode.Error);
    activity?.AddEvent(new ActivityEvent("exception", tags: new ActivityTagsCollection {
        { "exception.type", ex.GetType().FullName },
        { "exception.message", ex.Message },
        { "exception.stacktrace", ex.ToString() }
    }));
    throw;
}

[baronfel]

The good news is that this is automatically done for us. The BCL listeners already catch and finalize activities where exceptions are thrown in much the same way that you've suggested here. The whole system does so much correct out of the box for you, it's really a joy.

[nagilson]

That is awesome!

[KalleOlaviNiemitalo]

The BCL listeners already catch and finalize activities where exceptions are thrown in much the same way that you've suggested here.

I searched for ActivityStatusCode.Error references at https://source.dot.net/ but I don't see any activity listeners setting that. AFAICT, it's instead done by the code that has an ActivitySource and starts and stops an Activity. I therefore don't agree with "this is automatically done for us".

[nagilson]

Thanks, I think this is a great idea. I didn't know about system.diagnostics.

It looks like it collects perf data for us too, which is great. We should likely inform aspire once this is merged how to enable the telemetry.