dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.72k stars 1.07k forks source link

Dotnet SDK 8 breaks deterministic builds #37371

Open maltalex opened 11 months ago

maltalex commented 11 months ago

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.
jackobo commented 2 weeks ago

Will this be ever fixed ?