Open ladipro opened 1 month ago
Goot catch and analysis!
Apparently the BuildEventContext
is currently good for logging only in the node that created it via LogProjectStarted
- as that's the only place where the _projectFileMap
is filled (appart from project caching scenarios - that we can igfnore here):
The other interresting thing is that this doesn't manifest in the out-of-proc end-2-end unit tests - this is given by the fact that ProjectContextId
of the transfered BuildEventContext
(attached to the BuildEvent
) is initialized to invalid project (-2).
So it means:
BuildEventContext
is properly remoted and deserialized. As a result the SampleAnalyzerIntegrationTest
should fail for the buildInOutOfProcessNode
case._projectFileMap
in the LoggingService
on the receiving side (scheduler node) as well. As a result the failing tet should be fixed againSampleAnalyzerIntegrationTest
Issue Description
When a build check subscribes to task invocation events and attempts to report a result from its task invocation action, MSBuild sometimes crashes with
ContextID {0} should have been in the ID-to-project file mapping but wasn't!
.Steps to Reproduce
Reproduced with the upcoming
DoubleWritesAnalyzer
, for example.Expected Behavior
The analyzer can report results from the task invocation action.
Actual Behavior
When building a larger solution with
/m
, the build fails withContextID {0} should have been in the ID-to-project file mapping but wasn't!
at this callstack:Analysis
Build check infra uses the
BuildEventContext
as passed to theAnyEventRaised
handler of the build check logger. Apparently this context is not good for raising new events. It's not immediately clear to me where the bug is - either build check infra shouldn't be reusing the incoming context (because it could come from another node?) or logging infra should properly translate it when moving across processes. cc @JanKrivanek.Versions & Configurations
MSBuild.exe built at commit 2d924ca8c28f63e3b562f05525a4fd4cb8c792aa