Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dotnet SDK 8 breaks deterministic builds #37371

Open
maltalex opened this issue Dec 7, 2023 · 1 comment
Open

Dotnet SDK 8 breaks deterministic builds #37371

maltalex opened this issue Dec 7, 2023 · 1 comment
Assignees
Labels
Area-NetSDK untriaged Request triage from a team member

Comments

@maltalex
Copy link

maltalex commented Dec 7, 2023

Describe the bug

Since dotnet 8 enables source link by default, deterministic builds now depend on the state of the git repo at build time. This is not one of the inputs that affects determinism according to the documentation.

Two identical projects built deterministically will now produce a different binary depending on the state of the repository they are located in. This breaks some automation flows that rely identical sources producing identical binaries.

To Reproduce

Create a two commits with identical sources, build both with Deterministic=true. Observe that the resulting assemblies aren't identical.

For reference, the current documentation about deterministic builds:

By default, compiler output from a given set of inputs is unique, since the compiler adds a timestamp and an MVID (a Module.ModuleVersionId. Basically it is a GUID that uniquely identifies the module and version.) that is generated from random numbers. You use the option to produce a deterministic assembly, one whose binary content is identical across compilations as long as the input remains the same. In such a build, the timestamp and MVID fields will be replaced with values derived from a hash of all the compilation inputs. The compiler considers the following inputs that affect determinism:

The sequence of command-line parameters.
The contents of the compiler's .rsp response file.
The precise version of the compiler used, and its referenced assemblies.
The current directory path.
The binary contents of all files explicitly passed to the compiler either directly or indirectly, including:
    Source files
    Referenced assemblies
    Referenced modules
    Resources
    The strong name key file
    @ response files
    Analyzers
    Rulesets
    Other files that may be used by analyzers
The current culture (for the language in which diagnostics and exception messages are produced).
The default encoding (or the current code page) if the encoding isn't specified.
The existence, non-existence, and contents of files on the compiler's search paths (specified, for example, by -lib or -recurse).
The Common Language Runtime (CLR) platform on which the compiler is run.
The value of %LIBPATH%, which can affect analyzer dependency loading.
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Dec 7, 2023
@jackobo
Copy link

jackobo commented Oct 31, 2024

Will this be ever fixed ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

3 participants