-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Prevent CS0121 (ambiguous method calls) resulting from config binding source gen #86363
Comments
Tagging subscribers to this area: @dotnet/area-extensions-configuration Issue DetailsFrom @andrewlock in #44493 (comment): One potential issue I can foresee with the design of the generated code (because I've run into a similar issue with my own generators) is around The fact that the generated code is always a fixed type ( Project 1: [assembly:InternalsVisible2(Project2)]
var config = new ConfigurationBuilder().Build();
var settings = new SomeOptions();
section.Bind(settings); Project 2: (has a var config = new ConfigurationBuilder().Build();
var settings = new MoreOptions();
section.Bind(settings); // 👈 error Gives
You might consider it an edge case, but it was one of the first issues I ran into when building my first source generator. Note: I've just seen that preview 4 bits are going onto NuGet, so apologies if this is no longer relevant! :D (Edit: looks like the preview 3 package is broken for me)
|
FYI @davidfowl @eerhardt @ericstj re: #44493 (comment). |
@andrewlock do you also have |
@tarekgh @eerhardt @ericstj, does it seem reasonable to generate random names to avoid the clashes? Thinking we can make this change when we adopt the Roslyn interceptors feature. Right now this name clash issue doesn't seem crucial for 8.0, pending feedback from @andrewlock. |
I have done similar things in the options source gen if you want to take a look at #89148 |
There was discussion in #90340 (comment) about the right approach to avoid name clashes. This needs to be addressed for the options generator, and I'd have to validate interception behavior in the config generator. |
We're sticking with the interceptors approach for RC-1, where this problem does not arise. Options generator changes are being tracked in #90990. |
From @andrewlock in #44493 (comment):
One potential issue I can foresee with the design of the generated code (because I've run into a similar issue with my own generators) is around
internal
classes andInternalsVisibleTo
.The fact that the generated code is always a fixed type (
GeneratedConfigurationBinder
) in the global namespace, means that something like this will no longer compile:Project 1:
Project 2: (has a
<ProjectReference>
to Project1)Gives
You might consider it an edge case, but it was one of the first issues I ran into when building my first source generator.
Note: I've just seen that preview 4 bits are going onto NuGet, so apologies if this is no longer relevant! :D (Edit: looks like the preview 3 package is broken for me)
The text was updated successfully, but these errors were encountered: