dotnet
Binaries don't build deterministically locally due to source link changes
The following binaries are no longer building deterministically.
- Microsoft.CodeAnalysis.CSharp.Scripting.Desktop.UnitTests.dll
- Microsoft.CodeAnalysis.CSharp.Scripting.UnitTests.dll
- Microsoft.CodeAnalysis.CSharp.Scripting.UnitTests.dll
- Microsoft.CodeAnalysis.Scripting.TestUtilities.dll
- Microsoft.CodeAnalysis.Scripting.TestUtilities.dll
- Microsoft.CodeAnalysis.Scripting.UnitTests.dll
- Microsoft.CodeAnalysis.Scripting.UnitTests.dll
- Microsoft.CodeAnalysis.VisualBasic.Scripting.Desktop.UnitTests.dll
- Microsoft.CodeAnalysis.VisualBasic.Scripting.UnitTests.dll
The actual code contents are all building deterministically here but the PDB contents are difference in the rebuld. That it turn changes the PDB ID which changes the checksum of the DLLs since it embeds the PDB. The difference can be observed here
The PDB diff isn't obvious here. Used a couple of tools to dump the PDB to text and they all had the same text output. Diffing a hexdump of the binaries though reveals some differences
Spent a few hours debugging this last night and it's not specific to the scripting binaries. This is also a general problem I was seeing on my machine that just happened to hit scripting first.
The root problem I found is that several parts of our generated AssemblyInfo.cs files were non-deterministic. On a typical run the file should have the following two attribute definitions:
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("3.9.0-ci")]
...
[assembly: System.Reflection.AssemblyMetadataAttribute("RepositoryUrl", "https://github.com/dotnet/roslyn.git")]
When running builds in a loop locally though I will occasionally see the following
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("3.9.0-dev")]
...
[assembly: System.Reflection.AssemblyMetadataAttribute("RepositoryUrl", "file://p:\\roslyn\\")]
This in turn leads to the contents of the assembly consuming this to change and hence determinism breaks. What is truly odd about this is that there is no evidence of this change in the binlog files that are generated during build. I was able to track the attribute generation in all of the binlog files and they always show the typical values, not the atypical ones. At one point I convinced myself I must have stale data somewhere on my machine and nuked every asset I could think of and still the problem continued to happen.
The only explanation I could think of which would explain everything I saw is if another process was regenerating the files while I was building. Could find no evidence of this happening though.
My gut says I'm doing something really silly here that is causing the problem but I can't see it.
