Skip to content
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.

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

Properties and items aren't logged at evaluation for dotnet build #23248

Closed
KirillOsenkov opened this issue Jan 4, 2022 · 11 comments
Closed
Labels
Area-NetSDK untriaged Request triage from a team member

Comments

@KirillOsenkov
Copy link
Member

Unlike MSBuild, when you run dotnet build, something is preventing the new behavior of logging properties and items after evaluation.

As a result we get legacy broken behavior where some properties and items are logged for some projects at ProjectStarted, but not others, and none at all are logged at evaluation.

This is very bad and we should fix this soon.

@ghost ghost assigned KirillOsenkov Jan 4, 2022
@KirillOsenkov
Copy link
Member Author

dotnet msbuild doesn't work either.

@KirillOsenkov
Copy link
Member Author

This needs to be opted into IEventSource4:

if (eventSource is IEventSource2 eventSource2)

@ghost ghost assigned rainersigwald Jan 4, 2022
@rainersigwald rainersigwald transferred this issue from dotnet/msbuild Jan 4, 2022
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Jan 4, 2022
@KirillOsenkov
Copy link
Member Author

I saw six loggers under debugger, any idea if there are more?

@rainersigwald
Copy link
Member

AFAIK this is the only default addition:

$"-distributedlogger:{loggerType.FullName},{loggerType.GetTypeInfo().Assembly.Location}*{forwardingLoggerType.FullName},{forwardingLoggerType.GetTypeInfo().Assembly.Location}"

I also pointed you to the wrong implementation of the logger offline--we pass both the distributed and central logger, but it seems only the central logger needs to opt in for everything to work.

@KirillOsenkov
Copy link
Member Author

Yes, seems reasonable: I saw 3 loggers on the build parameters, I'm guessing those are: Console, BinaryLogger and this logger. I saw 6 loggers on the LoggingService, and it means one central, one forwarding for each of those??

So it adds up. When we have a build of dotnet with this change, a simple way to test is just build any project with console and /bl and see if the evaluations have properties and items:

image

@rainersigwald
Copy link
Member

Yup, that's what I see with my private build:

image

@KirillOsenkov
Copy link
Member Author

Amazing!

I'm also thinking that currently if there are unenlightened loggers, there's no way to force the new behavior.

We should respect the environment variable if set, and force it to true regardless of which loggers. This would give us a way to turn it on via an environment variable as a workaround. Would have really saved my bacon right about now :)

@KirillOsenkov
Copy link
Member Author

Something like this in the LoggingService.cs?

image

@KirillOsenkov
Copy link
Member Author

I can PR this in a sec

@rainersigwald
Copy link
Member

Yeah, I'd be on board for that.

@KirillOsenkov
Copy link
Member Author

dotnet/msbuild#7217

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

2 participants