Skip to content

Conversation

jasonmalinowski
Copy link
Member

@jasonmalinowski jasonmalinowski commented Sep 3, 2025

This improves some logging and handling in error situations for our ServiceHub MEF creation. Review commit-at-a-time.

We use this log since if things go terribly bad during initialization
we might not actually get error information back to the devenv process,
and we don't have telemetry active at that point to report to either.
The CompositionErrors collection is ordered -- the first set of errors
are the "root" errors, then there are follow up sets that are downstream
failures from those first ones. Since our code was only looking at the
first set, it's possible that an "expected" failure there might still
cause downstream issues which could break the rest of the system.
We already have this, it seems odd not to pass it along.
@jasonmalinowski jasonmalinowski self-assigned this Sep 3, 2025
@jasonmalinowski jasonmalinowski requested a review from a team as a code owner September 3, 2025 20:41
}

protected override void LogTrace(string message)
{
_traceLogger.TraceEvent(TraceEventType.Information, 0, message);
Copy link
Member

@dibarbet dibarbet Sep 3, 2025

Choose a reason for hiding this comment

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

Is Information the level that normally gets logged? I think it would be good if these are logged by default (since it only happens once at startup and isn't generally in a user facing log)

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh right I forgot to dig into this: the default seems to be warning-level stuff gets logged only. We need to figure out where that configuration comes from.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's not configurable. The belief is anything interesting for now we're logging at warning or higher, and we should ask the ServiceHub folks for a setting to let this be specified differently in the manifest.

@@ -208,7 +208,7 @@ private bool CheckForAndReportCompositionErrors(CompositionConfiguration configu
catch (CompositionFailedException ex)
{
// The ToString for the composition failed exception doesn't output a nice set of errors by default, so log it separately
LogError($"Encountered errors in the MEF composition: {ex.Message}{Environment.NewLine}{ex.ErrorsAsString}");
LogError($"Encountered errors in the MEF composition: {ex.ErrorsAsString}", ex);
Copy link
Member

Choose a reason for hiding this comment

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

Errors as string can be pretty long (and IIRC contains new lines itself) - probably should be started on a new line?

Copy link
Member Author

Choose a reason for hiding this comment

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

Newline added.

@jasonmalinowski jasonmalinowski merged commit a70b5c1 into dotnet:main Sep 3, 2025
25 checks passed
@jasonmalinowski jasonmalinowski deleted the improve-mef-creation-and-logging branch September 3, 2025 23:00
@jasonmalinowski
Copy link
Member Author

/backport to release/dev18.0

@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Sep 3, 2025
Copy link
Contributor

github-actions bot commented Sep 3, 2025

Started backporting to release/dev18.0: https://github.com/dotnet/roslyn/actions/runs/17448217047

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

Successfully merging this pull request may close these issues.

4 participants