Given two msbuild log events X and Y where X.Timestamp < Y.Timestamp is it true that event X started running before the event Y?
We are talking about parallel build. The two events are the following:
- MSBuild
TaskStarted ProjectStarted
OR
ProjectFinished- MSBuild
TaskFinished
So if MSBuild TaskStarted.Timestamp < ProjectStarted.Timestamp, then the MSBuild task in question started earlier than the project.
EDIT 1
I am trying to establish parent-child relationship between msbuild events. The trickiest is between MSBuild TaskStarted and ProjectStarted. The TaskStarted (i.e. the task) can be the parent of the given ProjectStarted (i.e. the project), but in the log they often have the same timestamp and belong to different msbuild nodes. I am still able to correlate between them using another assumption I make (Is it true that `ProjectStartedEventArgs.TargetNames` is identical for all the child projects invoked from the same MSBuild task?). Whoever, I have cases where my code breaks, because it seems that a child ProjectStarted event has smaller timestamp than its parent MSBuild TaskStarted event.
msbuild
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
add a comment |
We are talking about parallel build. The two events are the following:
- MSBuild
TaskStarted ProjectStarted
OR
ProjectFinished- MSBuild
TaskFinished
So if MSBuild TaskStarted.Timestamp < ProjectStarted.Timestamp, then the MSBuild task in question started earlier than the project.
EDIT 1
I am trying to establish parent-child relationship between msbuild events. The trickiest is between MSBuild TaskStarted and ProjectStarted. The TaskStarted (i.e. the task) can be the parent of the given ProjectStarted (i.e. the project), but in the log they often have the same timestamp and belong to different msbuild nodes. I am still able to correlate between them using another assumption I make (Is it true that `ProjectStartedEventArgs.TargetNames` is identical for all the child projects invoked from the same MSBuild task?). Whoever, I have cases where my code breaks, because it seems that a child ProjectStarted event has smaller timestamp than its parent MSBuild TaskStarted event.
msbuild
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
With 'triggered', you actually mean 'triggered' (as in, some kind of signal was given that something can start which might not necessarily be the same as actually having started) or rather 'executed' or 'started'?
– stijn
Nov 14 '18 at 18:52
I added clarifications
– mark
Nov 15 '18 at 14:21
Skimming through the source code, I'd say it might depend on the time difference: if it's like seconds earlier, then yes it probably did start earlier. Reason: as fas as I can tell the timestamp in the log event gets created right before the task gets executed. However it seems that execution might actually take place on another thread so it could be possible X gets logged, then Y gets logged, then Y starts, then X starts. But I assume the timestamps would be very close though. But maybe if you clarify what you actually want to know there might be other ways than timestamps..
– stijn
Nov 15 '18 at 17:28
add a comment |
We are talking about parallel build. The two events are the following:
- MSBuild
TaskStarted ProjectStarted
OR
ProjectFinished- MSBuild
TaskFinished
So if MSBuild TaskStarted.Timestamp < ProjectStarted.Timestamp, then the MSBuild task in question started earlier than the project.
EDIT 1
I am trying to establish parent-child relationship between msbuild events. The trickiest is between MSBuild TaskStarted and ProjectStarted. The TaskStarted (i.e. the task) can be the parent of the given ProjectStarted (i.e. the project), but in the log they often have the same timestamp and belong to different msbuild nodes. I am still able to correlate between them using another assumption I make (Is it true that `ProjectStartedEventArgs.TargetNames` is identical for all the child projects invoked from the same MSBuild task?). Whoever, I have cases where my code breaks, because it seems that a child ProjectStarted event has smaller timestamp than its parent MSBuild TaskStarted event.
msbuild
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
We are talking about parallel build. The two events are the following:
- MSBuild
TaskStarted ProjectStarted
OR
ProjectFinished- MSBuild
TaskFinished
So if MSBuild TaskStarted.Timestamp < ProjectStarted.Timestamp, then the MSBuild task in question started earlier than the project.
EDIT 1
I am trying to establish parent-child relationship between msbuild events. The trickiest is between MSBuild TaskStarted and ProjectStarted. The TaskStarted (i.e. the task) can be the parent of the given ProjectStarted (i.e. the project), but in the log they often have the same timestamp and belong to different msbuild nodes. I am still able to correlate between them using another assumption I make (Is it true that `ProjectStartedEventArgs.TargetNames` is identical for all the child projects invoked from the same MSBuild task?). Whoever, I have cases where my code breaks, because it seems that a child ProjectStarted event has smaller timestamp than its parent MSBuild TaskStarted event.
msbuild
msbuild
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
edited Nov 16 '18 at 0:59
mark
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
asked Nov 14 '18 at 12:53
markmark
19.8k56186377
19.8k56186377
With 'triggered', you actually mean 'triggered' (as in, some kind of signal was given that something can start which might not necessarily be the same as actually having started) or rather 'executed' or 'started'?
– stijn
Nov 14 '18 at 18:52
I added clarifications
– mark
Nov 15 '18 at 14:21
Skimming through the source code, I'd say it might depend on the time difference: if it's like seconds earlier, then yes it probably did start earlier. Reason: as fas as I can tell the timestamp in the log event gets created right before the task gets executed. However it seems that execution might actually take place on another thread so it could be possible X gets logged, then Y gets logged, then Y starts, then X starts. But I assume the timestamps would be very close though. But maybe if you clarify what you actually want to know there might be other ways than timestamps..
– stijn
Nov 15 '18 at 17:28
add a comment |
With 'triggered', you actually mean 'triggered' (as in, some kind of signal was given that something can start which might not necessarily be the same as actually having started) or rather 'executed' or 'started'?
– stijn
Nov 14 '18 at 18:52
I added clarifications
– mark
Nov 15 '18 at 14:21
Skimming through the source code, I'd say it might depend on the time difference: if it's like seconds earlier, then yes it probably did start earlier. Reason: as fas as I can tell the timestamp in the log event gets created right before the task gets executed. However it seems that execution might actually take place on another thread so it could be possible X gets logged, then Y gets logged, then Y starts, then X starts. But I assume the timestamps would be very close though. But maybe if you clarify what you actually want to know there might be other ways than timestamps..
– stijn
Nov 15 '18 at 17:28
With 'triggered', you actually mean 'triggered' (as in, some kind of signal was given that something can start which might not necessarily be the same as actually having started) or rather 'executed' or 'started'?
– stijn
Nov 14 '18 at 18:52
With 'triggered', you actually mean 'triggered' (as in, some kind of signal was given that something can start which might not necessarily be the same as actually having started) or rather 'executed' or 'started'?
– stijn
Nov 14 '18 at 18:52
I added clarifications
– mark
Nov 15 '18 at 14:21
I added clarifications
– mark
Nov 15 '18 at 14:21
Skimming through the source code, I'd say it might depend on the time difference: if it's like seconds earlier, then yes it probably did start earlier. Reason: as fas as I can tell the timestamp in the log event gets created right before the task gets executed. However it seems that execution might actually take place on another thread so it could be possible X gets logged, then Y gets logged, then Y starts, then X starts. But I assume the timestamps would be very close though. But maybe if you clarify what you actually want to know there might be other ways than timestamps..
– stijn
Nov 15 '18 at 17:28
Skimming through the source code, I'd say it might depend on the time difference: if it's like seconds earlier, then yes it probably did start earlier. Reason: as fas as I can tell the timestamp in the log event gets created right before the task gets executed. However it seems that execution might actually take place on another thread so it could be possible X gets logged, then Y gets logged, then Y starts, then X starts. But I assume the timestamps would be very close though. But maybe if you clarify what you actually want to know there might be other ways than timestamps..
– stijn
Nov 15 '18 at 17:28
add a comment |
1 Answer
1
active
oldest
votes
I think the most reliable way to establish parent-child relationship between MSBuild events is by using the BuildEventContext. Each BuildEventArgs has a BuildEventContext:
https://source.dot.net/#Microsoft.Build.Framework/BuildEventArgs.cs,3ad27845b97a06b4
In it you can see the Node ID, which Project this event belongs to, which target (if any) and which task (if any). If the task is MSBuild (starts a build of another project) then the project's parent Task will point to that MSBuild task.
I wouldn't necessarily rely on timestamps to establish relationships, maybe only for temporal ordering (to display the events in the right logical order).
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is thatParentBuildEventContextdoes not contain the respectiveTaskIdvalue, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.
– mark
Nov 16 '18 at 22:48
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
1
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300711%2fgiven-two-msbuild-log-events-x-and-y-where-x-timestamp-y-timestamp-is-it-true%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think the most reliable way to establish parent-child relationship between MSBuild events is by using the BuildEventContext. Each BuildEventArgs has a BuildEventContext:
https://source.dot.net/#Microsoft.Build.Framework/BuildEventArgs.cs,3ad27845b97a06b4
In it you can see the Node ID, which Project this event belongs to, which target (if any) and which task (if any). If the task is MSBuild (starts a build of another project) then the project's parent Task will point to that MSBuild task.
I wouldn't necessarily rely on timestamps to establish relationships, maybe only for temporal ordering (to display the events in the right logical order).
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is thatParentBuildEventContextdoes not contain the respectiveTaskIdvalue, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.
– mark
Nov 16 '18 at 22:48
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
1
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
add a comment |
I think the most reliable way to establish parent-child relationship between MSBuild events is by using the BuildEventContext. Each BuildEventArgs has a BuildEventContext:
https://source.dot.net/#Microsoft.Build.Framework/BuildEventArgs.cs,3ad27845b97a06b4
In it you can see the Node ID, which Project this event belongs to, which target (if any) and which task (if any). If the task is MSBuild (starts a build of another project) then the project's parent Task will point to that MSBuild task.
I wouldn't necessarily rely on timestamps to establish relationships, maybe only for temporal ordering (to display the events in the right logical order).
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is thatParentBuildEventContextdoes not contain the respectiveTaskIdvalue, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.
– mark
Nov 16 '18 at 22:48
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
1
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
add a comment |
I think the most reliable way to establish parent-child relationship between MSBuild events is by using the BuildEventContext. Each BuildEventArgs has a BuildEventContext:
https://source.dot.net/#Microsoft.Build.Framework/BuildEventArgs.cs,3ad27845b97a06b4
In it you can see the Node ID, which Project this event belongs to, which target (if any) and which task (if any). If the task is MSBuild (starts a build of another project) then the project's parent Task will point to that MSBuild task.
I wouldn't necessarily rely on timestamps to establish relationships, maybe only for temporal ordering (to display the events in the right logical order).
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
I think the most reliable way to establish parent-child relationship between MSBuild events is by using the BuildEventContext. Each BuildEventArgs has a BuildEventContext:
https://source.dot.net/#Microsoft.Build.Framework/BuildEventArgs.cs,3ad27845b97a06b4
In it you can see the Node ID, which Project this event belongs to, which target (if any) and which task (if any). If the task is MSBuild (starts a build of another project) then the project's parent Task will point to that MSBuild task.
I wouldn't necessarily rely on timestamps to establish relationships, maybe only for temporal ordering (to display the events in the right logical order).
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
answered Nov 16 '18 at 21:49
Kirill OsenkovKirill Osenkov
7,01912528
7,01912528
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is thatParentBuildEventContextdoes not contain the respectiveTaskIdvalue, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.
– mark
Nov 16 '18 at 22:48
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
1
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
add a comment |
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is thatParentBuildEventContextdoes not contain the respectiveTaskIdvalue, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.
– mark
Nov 16 '18 at 22:48
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
1
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is that
ParentBuildEventContext does not contain the respective TaskId value, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.– mark
Nov 16 '18 at 22:48
I am doing exactly this. However, I witness a situation where many events arrive with exactly the same timestamp and they include multiple instances of MSBuild TaskStarted/TaskFinished and ProjectStarted/ProjectFinished events and there are more than one Project event that can match more than one Task event based on the NodeId and ParentId comparison. The problem is that
ParentBuildEventContext does not contain the respective TaskId value, only the NodeId and ProjectInstance,ContextId, which are not enough to disambiguate.– mark
Nov 16 '18 at 22:48
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
I am working to provide more information.
– mark
Nov 16 '18 at 22:49
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
This could be an MSBuild limitation - consider perhaps filing an MSBuild issue? github.com/Microsoft/MSBuild/issues
– Kirill Osenkov
Nov 17 '18 at 19:54
1
1
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
github.com/Microsoft/msbuild/issues/3939 Unfortunately, I still cannot provide more information. Working on it.
– mark
Nov 17 '18 at 20:29
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300711%2fgiven-two-msbuild-log-events-x-and-y-where-x-timestamp-y-timestamp-is-it-true%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
With 'triggered', you actually mean 'triggered' (as in, some kind of signal was given that something can start which might not necessarily be the same as actually having started) or rather 'executed' or 'started'?
– stijn
Nov 14 '18 at 18:52
I added clarifications
– mark
Nov 15 '18 at 14:21
Skimming through the source code, I'd say it might depend on the time difference: if it's like seconds earlier, then yes it probably did start earlier. Reason: as fas as I can tell the timestamp in the log event gets created right before the task gets executed. However it seems that execution might actually take place on another thread so it could be possible X gets logged, then Y gets logged, then Y starts, then X starts. But I assume the timestamps would be very close though. But maybe if you clarify what you actually want to know there might be other ways than timestamps..
– stijn
Nov 15 '18 at 17:28