MarkKharitonov

Note: the following code ignores nested types.

Without further ado, here is the code:

using ManyConsole;
using Microsoft.Build.Evaluation;
using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis.CSharp.Syntax;
using Newtonsoft.Json;

MarkKharitonov

The minimal reproduction contains

• 8 cs files - they are all very small, only one contains a non trivial function (~10 lines)
• 14 csproj files - most of them have no cs files at all, hence the compiler warnings about not seeing any source code at all
• 2 sln files - the problem reproduces in the second solution
• 1 dll file - that is the misreferenced binary that causes the recompilation bug

Reproduction notes

1. The repro.ps1 script assumes that msbuild runs MSBuild 15.
2. Running repro.ps1 -FromScratch reproduces the bug using the minimal reproduction available at the MSBuild15RecompilationBug github repository.
3. The generated binary logs are then analyzed using the tool available at the MSBuildBinaryLogAnalyzer github repository.

MarkKharitonov

There is file t.pgp which is encrypted using HashiCorp public key.

MarkKharitonov

Introduction

Our goal is to understand where the time goes in our builds. More importantly, we want other developers to be able see it easily and witness the improvement or degradation of the build performance. The binary log is great, but we cannot have each Pull Request validation build produce one because it prolongs the duration of the build itself significantly. Plus one cannot really draw charts and present dashboards from a collection of binary logs.

We have decided to write our own logger in order to measure the events and push them to Application Insights. I hope to be able to publish the source code on GitHub really soon.

Events

Our logger subscribes to the following msbuild events:

• BuildStarted/BuildFinished
  • Produces the single Build entity.
• ProjectStarted/ProjectFinished

MarkKharitonov

<#
.SYNOPSIS
    Runs a WinDBG command or a script file.
    
.DESCRIPTION
    Simetimes a WinDBG command produces a lot of output that we may not wish to see in the GUI. Sometimes we would like to run a complex post-processing on
    a WinDBG command output. These are two examples of cases when scripting WinDBG and redirecting the output into a file is what we want to do and this
    script is a way to do it.
    
    WinDBG and CDB are two front-ends for the same debugger. The difference is the user interface - WinDBG is a GUI whereas CDB is console based.