Source generation and user display language

[PetSerAl]

What is expected relation between content of automatically generated source files and user display language used in build?

1. Content can depend on user display language
2. Content can depend on user display language, but only in comments
3. Content can not depend on user display language (reproducible builds, etc.)

[vst121]

Content can not depend on user display language.

Automatically generated source files should be consistent and reproducible across different machines and environments, regardless of the user’s display language. If generated content varied based on locale, it would break reproducible builds and could introduce subtle bugs. Comments or metadata that appear to vary with language should be either neutralized or excluded from reproducible outputs.

[PetSerAl]

Can you provide reference to official documentation, that confirm this? My concern is that from first code commit in this repository:

msbuild/src/XMakeTasks/WriteCodeFragment.cs

Lines 184 to 185 in 82177a5

	string comment = ResourceUtilities.FormatResourceString("WriteCodeFragment.Comment", DateTime.Now.ToString());
	globalNamespace.Comments.Add(new CodeCommentStatement(comment));

up to this day (just tested on SDK 10.0.102):

msbuild/src/Tasks/WriteCodeFragment.cs

Lines 171 to 172 in 4f6355e

	string comment = ResourceUtilities.GetResourceString("WriteCodeFragment.Comment");
	globalNamespace.Comments.Add(new CodeCommentStatement(comment));

MSBuild do include comment from localized resource string into generated at build source file (AssemblyInfo.cs). Generation of this file is enabled by default. Although reference for current time was removed from comment.

[vst121]

You’re right that MSBuild has historically emitted localized comments into generated source files (including AssemblyInfo.cs), and your example from WriteCodeFragment is accurate. There does not appear to be an explicit statement in MSBuild documentation that forbids localized content in generated source files.

My point is based on documented goals and guidance around reproducible / deterministic builds, rather than a single rule targeting comments specifically.

Some relevant references:

• .NET deterministic builds
  Microsoft documents that deterministic builds aim to ensure that the same inputs produce the same outputs, byte-for-byte:
  https://learn.microsoft.com/dotnet/csharp/language-reference/compiler-options/deterministic-compiler-option

• Reproducible Builds (general principle)
  The reproducible-builds project explicitly lists locale, timezone, and environment-dependent data as common sources of non-reproducibility:
  https://reproducible-builds.org/docs/common-problems/

• MSBuild design direction
  MSBuild has been progressively removing sources of non-determinism over time (e.g., timestamps, machine paths, random ordering). The removal of DateTime.Now from the comment you cited is consistent with this direction, even though localized strings remain.

So, I agree with you that:

• MSBuild does currently include localized comments in generated source files
• This behavior has existed for a long time and is intentional

My argument is that:

• Locale-dependent content in generated source files is at odds with reproducible-build goals
• Even if it’s “only comments,” it still affects source output and diffs
• Ideally, generated source should be locale-neutral, or comments should be excluded from reproducible outputs

In other words, this is less about “MSBuild violates its own rules” and more about “there’s a tension between legacy behavior and modern reproducibility goals.”

[PetSerAl]

I file #13191.