Skip to content

Support ProjectConfigurationDescription when SDK loggers are attached#7297

Merged
rokonec merged 4 commits intodotnet:mainfrom
rainersigwald:fancy-formatting-works-in-cli
Feb 24, 2022
Merged

Support ProjectConfigurationDescription when SDK loggers are attached#7297
rokonec merged 4 commits intodotnet:mainfrom
rainersigwald:fancy-formatting-works-in-cli

Conversation

@rainersigwald
Copy link
Copy Markdown
Member

Unblocks dotnet/sdk#12030 by fixing problems that arose when combining dotnet build with ProjectConfigurationDescription.

Part of #1222.

I recommend reviewing commit-by-commit.

@rainersigwald rainersigwald added this to the VS 17.2 milestone Jan 14, 2022
@rainersigwald rainersigwald changed the title Support FormatEventMessage when SDK loggers are attached Support ProjectConfigurationDescription when SDK loggers are attached Jan 14, 2022
@rainersigwald rainersigwald marked this pull request as draft January 14, 2022 22:08
@rainersigwald rainersigwald force-pushed the fancy-formatting-works-in-cli branch from 92fc308 to 507db8f Compare January 14, 2022 22:38
@rainersigwald rainersigwald marked this pull request as ready for review January 14, 2022 23:17
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Checking _forwardingSetFromParameters here means that the logic is now order-dependent. If we hit a _forwardingTable key first, FORWARDPROJECTCONTEXTEVENTS will be ignored. If we hit FORWARDPROJECTCONTEXTEVENTS first, it will be applied. Is this intentional?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Mostly! At first I didn't do this, and some tests failed because they were specifying individual events and got more than they bargained for. I refactored to this and justify it like this: if you go to the trouble of specifying individual events we should respect that.

But I'm happy to hear other ideas/prioritizations!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Gotcha - and the only way to specify FORWARDPROJECTCONTEXTEVENTS is the new code in CreateForwardingLoggerRecord? Or is it possible that the logger will see, e.g.

FORWARDPROJECTCONTEXTEVENTS;LOWMESSAGEEVENT
and not
LOWMESSAGEEVENT;FORWARDPROJECTCONTEXTEVENTS
?

The two would have different behavior which I, as a drive-by reviewer, find suspicious.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

horribly: no, that's not the only way. You can in fact pass those on the command line, and you can horribly break logging today by doing, for instance:

msbuild -flp:v=diag .\MSBuild.Dev.slnf /clp:PROJECTSTARTEDEVENT /v:d
Microsoft (R) Build Engine version 17.1.0-preview-22055-02+797fd829a for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 1/20/2022 3:50:42 PM.

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:38.98

(note no actual output despite fairly high verbosity because most of the events were just dropped)

These are documented in https://docs.microsoft.com/visualstudio/msbuild/writing-multi-processor-aware-loggers. Do you think it would be reasonable to just not document FORWARDPROJECTCONTEXTEVENTS? I was hoping that that would get us to the point where we could say with some confidence "only we will add this and we will only ever append it so we can assume it's last". But that's not exactly an iron-clad guarantee.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do you think it would be reasonable to just not document FORWARDPROJECTCONTEXTEVENTS?

I think it's reasonable. Another option would be to document it, together with its overriding behavior, and tweak the code to just set a flag here and move the actual setting of _forwardingTable to ParseParameters. There is already some overriding implemented there so it wouldn't look out of place.

// Setting events to forward on the commandline will override the verbosity and other switches such as
// showPerfSummand and ShowSummary
if (_forwardingSetFromParameters)
{
_showPerfSummary = false;
_showSummary = true;
}

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I like that and switched to it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm somewhat confused by the naming here. should ForwardProjectContentsDescription be ForwardProjectContextDescription?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes!

@rainersigwald rainersigwald self-assigned this Feb 7, 2022
@rainersigwald rainersigwald force-pushed the fancy-formatting-works-in-cli branch from 507db8f to e4f71f7 Compare February 8, 2022 19:33
This was producing ugly strings like

    [S:\project.csproj:: TargetFramework=net5.0]

Instead, only add the space when there's something to separate.
Messages emitted directly from a project file (for instance via
`Warning` tasks) weren't getting the disambiguator, which seems wrong.
Using some fancier Shouldly features to make this test easier to understand.
@rainersigwald rainersigwald force-pushed the fancy-formatting-works-in-cli branch 2 times, most recently from 7f41230 to 41aeedf Compare February 8, 2022 20:08
@rainersigwald rainersigwald marked this pull request as draft February 9, 2022 16:27
@rainersigwald
Copy link
Copy Markdown
Member Author

Re-drafted because this isn't working right in conjunction with dotnet/sdk#12030. Looking.

dotnet/sdk#12030 discovered that the .NET SDK's default build process
didn't log TargetFramework details for normal projects.

This turned out to be because the .NET SDK attaches a custom logger,
which caused MSBuild to set up a ConfigurableForwardingLogger in front
of the ConsoleLogger that forwarded based on verbosity which wasn't high
enough to include the ProjectEvaluationFinished event.

Pass a new ConfigurableForwardingLogger parameter from the command line
handler to instruct it to pass those events even at lower verbosities.
@rainersigwald rainersigwald force-pushed the fancy-formatting-works-in-cli branch from 41aeedf to 6b58f62 Compare February 11, 2022 21:39
@rainersigwald
Copy link
Copy Markdown
Member Author

Ok, with #7386 + this PR, all looks good:

dotnet msbuild S:\play\multitargeted\multitargeted.csproj -t:rebuild
Microsoft (R) Build Engine version 17.2.0-dev-22111-01+f63aed75f for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

S:\play\multitargeted\multitargeted.csproj(8,5): warning : Warning from MSBuild target [TargetFramework=net48]
S:\play\multitargeted\Class1.cs(9,10): warning CS1030: #warning: 'Warning from C# in all TFs' [S:\play\multitargeted\multitargeted.csproj::TargetFramework=net48]
S:\play\multitargeted\Class1.cs(12,10): warning CS1030: #warning: 'Warning from C# in NETFRAMEWORK TF' [S:\play\multitargeted\multitargeted.csproj::TargetFramework=net48]
  multitargeted -> S:\play\multitargeted\bin\Debug\net48\multitargeted.dll
S:\play\multitargeted\multitargeted.csproj(8,5): warning : Warning from MSBuild target [TargetFramework=net5.0]
S:\play\multitargeted\Class1.cs(9,10): warning CS1030: #warning: 'Warning from C# in all TFs' [S:\play\multitargeted\multitargeted.csproj::TargetFramework=net5.0]
S:\play\multitargeted\Class1.cs(16,10): warning CS1030: #warning: 'Warning from C# in NETCOREAPP TF' [S:\play\multitargeted\multitargeted.csproj::TargetFramework=net5.0]
  multitargeted -> S:\play\multitargeted\bin\Debug\net5.0\multitargeted.dll

@rainersigwald rainersigwald marked this pull request as ready for review February 11, 2022 21:40
@rainersigwald rainersigwald added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Feb 17, 2022
@rokonec rokonec merged commit d846c19 into dotnet:main Feb 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: Logging merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants