Open rkieslinger opened 1 week ago
Do you have a simple small binlog with no secrets that exhibits the issue? Any chance you could email it to me at my first name dot last name at microsoft? Please don't share it if it contains any private information or secrets.
Unfortunately, no. As I mentioned in my initial post, rerunning the job almost always resolves the issue. I tested a binlog that failed on the first attempt by loading it with BinaryLog.ReadBuild()
50 times in a row in a sample console application on my local computer, and it worked every time.
I believe I can easily work around the issue by configuring my Hangfire job to automatically rerun if it fails, but I'm still curious about the root cause.
Could the size of the binlogs become an issue? They are currently around 60 MB. When opening a log in the MSBuild Structured Log Viewer, it states:
Total opening time: 33.642 s, Loading: 17.196 s, Analyzing: 2.478 s, Indexing: 11.128 s, Reading files: 785 ms, Allocated: 15 077 423 632 bytes, Nodes: 87 744 450, Strings: 263 925
No, the problem is with some property name or value. MSBuild logs all properties and their values on either ProjectEvaluationFinishedEventArgs or ProjectStartedEventArgs. When reading these properties it sorts them, and sometimes that comparer misbehaves, I don't know why.
could be related to machine culture/language
This could be a bug in .NET 9, we just call Array.Sort(): https://github.com/KirillOsenkov/MSBuildStructuredLog/blob/c140e9dd07ef9b2a12257f80873cfcf8126046ad/src/StructuredLogger/BinaryLogger/ArrayDictionary.cs#L230
Since migrating our project from .NET 8 to .NET 9 and updating the MSBuild.StructuredLogger NuGet package from version 2.2.356 to 2.2.386, we frequently encounter an exception at
BinaryLog.ReadBuild()
. Below is the stack trace:Since we are using Hangfire, we can rerun a job if it fails. If we encounter the aforementioned exception, the reruns almost always succeed.