Options source generator shouldn't use random names

[eerhardt]

runtime/src/libraries/Microsoft.Extensions.Options/gen/Emitter.cs

Lines 40 to 42 in 3ef2c80

	string suffix = $"_{new Random().Next():X8}";
	_staticValidationAttributeHolderClassName += suffix;
	_staticValidatorHolderClassName += suffix;

Generated code should be deterministic. Many companies and orgs have requirements around deterministic builds.

          Is this the code that prompted https://github.com/dotnet/roslyn-analyzers/pull/6882/? Should we change this code to not use Random, and instead be deterministic?

cc @jaredpar

Originally posted by @eerhardt in #89148 (comment)

[ghost]

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

Issue Details

---

Generated code should be deterministic. Many companies and orgs have requirements around deterministic builds.

          Is this the code that prompted https://github.com/dotnet/roslyn-analyzers/pull/6882/? Should we change this code to not use Random, and instead be deterministic?

cc @jaredpar

Originally posted by @eerhardt in #89148 (comment)

Author:	eerhardt
Assignees:	-
Labels:	untriaged, area-Extensions-Options, source-generator, needs-area-label
Milestone:	-

[tarekgh]

@jaredpar what is the suggestion here? We need to have a class name that is global internal and not conflict when two independent compilations using the generator and one of them is internal visible to the other one. The source gen supports Lang versions 8+. We already detect if using Lang Version 11+ we use file keyword and not using random at all.

[stephentoub]

what is the suggestion here?

Incorporate a hash of more data, like the assembly's name.

Or use C#11 and/or don't use InternalsVisibleTo.

[tarekgh]

Or use C#11 and/or don't use InternalsVisibleTo.

I want to avoid restricting the language version only because of that. I am not sure what do you mean by don't use InternalsVisibleTo.? It is the user who is using it and not the generator. Do you mean we shouldn't support this scenario? This is a real scenario we got from R9.

Incorporate a hash of more data, like the assembly's name.

This looks like a reasonable idea to try. Thanks!

[jaredpar]

I want to avoid restricting the language version only because of that.

I would start with requiring C# 11 and wait to see if users push back. Other generators like the regex generator have set that standard and, to my understanding at least, that has not been a problem thus far. I would not invest in making my generator more complex to support this scenario unless I had data saying that would be valuable.

[tarekgh]

@geeknoid @stephentoub @eerhardt would you be ok if we require Language version 11+ for the options source gen?

CC @ericstj

[stephentoub]

. I am not sure what do you mean by don't use InternalsVisibleTo.? It is the user who is using it and not the generator. Do you mean we shouldn't support this scenario?

I mean if incorporating assembly name is insufficient and you absolutely need IVT and you're using the options generator in two assemblies connected by IVT and you're using a language version less than 11, bump it to 11. This is why file exists.

[tarekgh]

This is fixed by #91432