Benefits over Broslyn

[slang25]

I stumbled on this project and it looks really cool, I was wondering if you've seen Broslyn, and what the benefits of complog are.

I can see that the the log would contain just the compiler related info, so would be much smaller, but are there other benefits?

[jaredpar]

I think I've run into Broslyn in the past and it definitely has overlap with compiler logs. At the core both projects are rooted in the idea of leveraging MSBuild binary logs to grab real compiler invocations then rehydrating roslyn objects like Compilation and Workspace on top of it. Based on brief look through I think the differences are:

1. Compiler logs are an artifact that is portable between machines. Essentially the output of complog create is a fancy zip file that can be transferred between machines with no loss of fidelity. This works well for scenarios where you want to build on one machine and run analysis using roslyn on another.
2. Both projects are a combination of tool and API. For compiler logs though the API appears to be larger and give customers a lot more control over how items are loaded. This was done to satisfy a number of tools that run in AzDO / GHA that had requirements on how to look at the projects.
3. Compiler logs can replay / rehydrate builds without running analyzers / generators. At the point a compiler log is captured the output of generators are stored in the log. That means a compiler log can be replayed / rehydrated without running any 3rd party code. That was an important goal given the number of places we use this tooling.
4. Broslyn is a much cooler name.

(1) above is particularly important to the C# compiler team as a significant part of our job is digging into bugs, perf, etc ... in customer builds. Compiler logs mean we no longer have to replicate customer's build environments. Instead they run their build, create a compiler log off of it, share it with us and we can replicate the compiler invocation locally. These days most of our build investigation are done on compiler logs that customers send.

@xoofx

[slang25]

Thanks for taking the time to explain the scenarios @jaredpar, I see this being really useful to the compiler team.

I've been keeping an eye on this space, my scenario is that I have a tool that pulls down hundreds of repos from our internal GitHub and does analysis of the code. Things like "Who publishes what messages use these frameworks", and all sorts of odd adhoc questions we want to get answers to. As these apps are on different versions of dotnet (some .NET Framework), built on different OSs, I use Buildalyzer and hope for the best, which gives surprisingly good results, but there are always cases where it just doesn't work.

I'd love for there to be some way for a codebase to express in a light touch way "here's how you can reliably get a Roslyn workspace for me", and this format might be a solution to that. We'd probably have to figure out how to standardize creation of these in our workflows and store the complogs in a central registry, but it might be worth the effort 🤔

[jaredpar]

I'd love for there to be some way for a codebase to express in a light touch way "here's how you can reliably get a Roslyn workspace for me",

I share this goal and it's something compiler logs are meant to solve. Basically if you want to analyze a build after the fact then just create a compiler log as part of the build pipeline and stash it in the artifacts for that build. Then you can come back later walk the latest build pipeline, grab the compiler log and go.