Add pre-MSBuild submission duration metric

[OvesN]

Fixes dotnet/msbuild#14537

Summary

• Add dotnet.cli.managed_entry_to_msbuild_submission.duration for dotnet pack and
  dotnet publish.
• Reuse the existing preTelemetry timestamp captured at the start of the managed CLI
  Program initializer.
• Record immediately before the first MSBuild invocation, including file-based projects.
• Exclude native host and CLR startup time; include managed CLI initialization, argument
  parsing, project or solution discovery, and Pack/Publish release-property evaluation.
• Add a MeterListener unit test for the duration, unit, and command tag.

The existing root main activity remains backdated to process start for end-to-end CLI timing.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟡 Changes recommended

MSBuildSubmissionMetricCommandName is declared as non-nullable but is used/assigned as nullable, making the contract misleading and increasing future null-deref risk.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR introduces a new CLI histogram metric to measure elapsed time from dotnet process start until the first MSBuild submission for dotnet pack and dotnet publish, and adds a unit test validating the metric’s unit and command tag.

Changes:

• Add CliMetrics (meter + histogram) and helper methods to record dotnet.cli.process_start_to_msbuild_submission.duration.
• Wire metric recording into both physical and file-based project paths via RestoringCommand and VirtualProjectBuildingCommand.
• Add a MeterListener test to validate the histogram emits seconds and the command.name tag.

File summaries

File	Description
test/dotnet.Tests/TelemetryTests/CliMetricsTests.cs	Adds a unit test validating metric emission and tags via MeterListener.
src/Cli/Microsoft.DotNet.Cli.Utils/CliMetrics.cs	Introduces the dotnet-cli meter + histogram and recording helpers.
src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs	Records the metric before starting MSBuild operations for file-based scenarios.
src/Cli/dotnet/Commands/Restore/RestoringCommand.cs	Records the metric before the first restore/MSBuild invocation for physical project scenarios.
src/Cli/dotnet/Commands/Publish/PublishCommand.cs	Sets the command tag value (publish) on the executed command instance.
src/Cli/dotnet/Commands/Pack/PackCommand.cs	Sets the command tag value (pack) on the executed command instance (MSBuild-based path).
src/Cli/dotnet/CommandBase.cs	Adds a per-command field and helper to record the metric once.

Review details

• Files reviewed: 7/7 changed files
• Comments generated: 1
• Review effort level: Lite

[ViktorHofer]

Does this number include the CLR start-up time?

[OvesN]

yes

[ViktorHofer]

Is this a useful metric then? The start-up time even with NativeAOT isn't stable. Do we have an existing metric when dotnet.dll starts executing code?

[OvesN]

Mmm.. I am not usre that we have such metric when  dotnet.dll  starts executing.. If start up time is so noisy so mb not to use Process.GetCurrentProcess().StartTime.ToUniversalTime(); but use start time from Program constructor? What do you think

[ViktorHofer]

I would be surprised if this is the first telemetry that needs to subtract the start-up time. @baronfel do you know of an existing pattern in dotnet.dll that we could reuse?

[baronfel]

We already track this time as part of the activity that is started first in the native entry point and the managed Program Main - check there first. We snapshot the process start time (which is not the time that Main was entered), grab the current time, and subtract to get the amount of time native host startup (and coreclr startup for the managed path) took.

[OvesN]

Thnx, now I use existing  preTelemetry  timestamp from  Program.cs. + I also renamed the metric so it will be more clear that we do not measure start up time

[baronfel]

I kind of don't agree with the direction overall. I think there's a way to get this data that is more integrated with the way the dotnet CLI is already 'naming' phases of work.

[baronfel]

This feels far too specific to me to have as a general metric. In general I'd think of the dotnet CLI as we think of the evaluation phase in msbuild - there are various 'phases' of work that take different times:

• process startup
• first-time CLI run overhead
• argument parsing
• command invocation

and then those individual commands may have other sub-phases. for example, pack may have

• evaluate to discover pack settings
• actual msbuild submission

In the CLI today, these phases are modeled as Spans - a concept from OpenTelemetry that is a timed unit of work that has various pieces of metadata that can be attached to it. In .NET Spans are most often surfaced as System.Diagnostics.Activities.Activity instances - you can see them being created across Program.cs and the NativeEntryPoint.cs already to track such interesting areas of time.

The way I'd been thinking that we would gather this information today is by adding an activity for the MSBuild submission portion of the MSbuild-using commands - this activity will be automatically visible in OTel viewers. Then, if we need a System.Diagnostics.Meter metric specifically for collection in crank or other scenarios, we can add an ActivityListener in the dotnet CLI that would publish histogram-style metrics for the activities:

var listener = new ActivityListener
{
    ShouldListenTo = source => source.Name == "dotnet-cli",
    Sample = (ref ActivityCreationOptions<ActivityContext> options) => ActivitySamplingResult.AllDataAndRecorded,
    ActivityStopped = activity =>
    {
        double durationMs = activity.Duration.TotalMilliseconds;
        Instruments.ActivityDuration.Record(durationMs, new KeyValuePair<string, object?>("activity.name", activity.OperationName));
    }
};

ActivitySource.AddActivityListener(listener);

From there dotnet-counters, Crank, etc can easily compute the deltas of the time - subtracting the time for the msbuild submission activity from the time of the overall command.

[baronfel]

I don't like having to know this to generate timestamps - the Activities we create already capture this data and I think we should be leaning into them more.