Monthly Archives: April 2018

Project System Tools: Now With Binary Log Viewing!

There has been a lot of positive response to the Project System Tools extension, and we’re starting to see people turn to it to help diagnose design-time build (and other build) issues. One of the limitations of the extension has been the fact that once a build log has been captured, there was no native way to look at the log in Visual Studio. Either you had to run it through MSBuild to get a text log, or you had to install Kirill’s excellent MSBuild Log Viewer. To address this limitation, we’re releasing a new version of the project system tools that integrates a Build Log Explorer window:

Once you’ve updated the extension, you can find the viewer at View > Other Windows > Build Log Explorer. The window should be fairly self-explanatory—the Add toolbar button will let you add one or more .binlog files into the explorer, or you can double-click on a log in the Build Logging tool window to add it to the explorer window. (We opted for a multi-log window to allow for the future ability to analyze across multiple build logs.) You will likely also want to show the View > Other Windows > Build Message List window, as that will show any MSBuild messages associated with the selected node in the explorer window. You’ll also note that the Properties window will show properties of the selected node in the explorer window (for example, clicking on a project build node will show the environment used to build the project in the properties window).

The Build Log Explorer window used Kirill’s code as a starting point but has diverged significantly in several ways:

  • The Build Log Explorer uses a standalone read-only build log object model as its underlying data model (Microsoft.VisualStudio.ProjectSystem.LogModel.dll), which will make it easier to build command-line log analysis tools (since it only depends on MSBuild and nothing else).
  • The Build Log Explorer window shows execution times and success/failure directly in the tree.
  • Targets are listed in execution order rather than arranged as a tree since targets aren’t executed in a strict hierarchical order (instead you have before/depends/after targets).
  • Targets that were the requested targets in a build are bolded.
  • Dependent builds are listed under the MSBuild task that invokes them, which makes it easier to follow the order of build.

Give it a try and let us know what you think!

You can also follow me on Twitter here.