build libs with `/p:Deterministic=true` some libraray make diff

[srxqds]

I build libs with /p:Deterministic=true with the below command:

./build.cmd -pack -runtimeFlavor mono /p:Deterministic=true

when I rebuild some libraries generate diff:

Is there tool to check they are the same code assembly?

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Author:	srxqds
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[ViktorHofer]

@ericstj this sounds important to fix but not block .NET 7 GA. Let's investigate and schedule a fix for soon after GA to not disrupt the existing builds?

[ericstj]

The screenshot shows differences with assemblies from multiple layers of the stack. System.Private.Xml sticks out as it is pretty low and I wouldn't expect it to rebuild. That might be an interesting first place to look. Essentially find the lowest component in the stack and answer the question "why did this rebuild?" keep pushing down if the answer to that question is "due to a reference changing".

[srxqds]

Is there any tool to analyze assembly diffs?

[ViktorHofer]

Is there any tool to analyze assembly diffs?

There are many on the market, i.e. JustAssembly or assembly-differ. I usually diff them manually by looking at the ildasm output or inspecting the assemblies via ilspy.

That said, in this case I would recommend to instead look at the build logfiles which should indicate what hinders the deterministic build. Usually you would produce an msbuild bin log via the /bl flag and then open it with the msbuild bin log viewer.

[ViktorHofer]

I build libs with /p:Deterministic=true with the below command:

The deterministic property already defaults to true since a few years. You don't need to pass it in yourself.

I couldn't reproduce the issue when just building the libraries:

dotnet.cmd libs -allconfigurations && dotnet.cmd libs -allconfigurations /bl

The binlog of the second build doesn't show any csc task invocations which means the compiler wasn't invoked. I will follow your exact command later.

That said, I found an interesting bug that was introduced last Saturday which will be fixed with #77110.

[ViktorHofer]

@srxqds unfortunately I can't reproduce your described issue when targeting main. I didn't test with release/7.0.

This issue has been marked needs-author-action and may be missing some important information.

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.