Configuration binder generator creates namespace ambiguity error

[paulguz-datapa]

Description

After upgrading our ASP.Net 7 application (that started life as Core 1.1 and upgraded through several .Net Core versions) to .Net 8, when building in a DevOps pipeline, the following error happens:

BindingExtensions.g.cs(131,71): error CS0104: 'Options' is an ambiguous reference between 'myProject.Options' and 'Microsoft.Extensions.Options.Options'

According to the docs, the Configuration Binding Source Generator is disabled by default, yet we have needed to add <EnableConfigurationBindingGenerator>false</EnableConfigurationBindingGenerator> to the csproj to work around the error. We are not using AOT, and never have.

Note, the project references a Microsoft.NET.Sdk.BlazorWebAssembly project. I'm not sure if that's relevant.

Reproduction Steps

• Take an existing .Net 7 web project,
• put an Options class in the root namespace and use with WebApplicationBuilder.Services.Configure.
• Upgrade to .Net 8.
• Do not intentionally enable the Configuration-binding source generator.
• Do not use AOT

Expected behavior

Project should build successfully. Configuration-binding source generator should not be enabled.

Actual behavior

Project fails to build with the following error:

BindingExtensions.g.cs(131,71): error CS0104: 'Options' is an ambiguous reference between 'myProject.Options' and 'Microsoft.Extensions.Options.Options'

Configuration-binding source generator appears to be enabled despite it supposedly being disabled by default.

Regression?

No response

Known Workarounds

<EnableConfigurationBindingGenerator>false</EnableConfigurationBindingGenerator> in the csproj

Configuration

.Net 8

Other information

No response

[ghost]

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

Issue Details

---

### Description After upgrading our ASP.Net 7 application (that started life as 1.1 and upgraded through several .Net Core versions) to .Net 8, when building in a DevOps pipeline, the following error happens: `BindingExtensions.g.cs(131,71): error CS0104: 'Options' is an ambiguous reference between 'myProject.Options' and 'Microsoft.Extensions.Options.Options'` According to the [docs](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8#configuration-binding-source-generator), the Configuration Binding Source Generator is disabled by default, yet we have needed to add false to the csproj to work around the error. ### Reproduction Steps - Take an existing .Net 7 web project, - put an Options class in the root namespace and use with WebApplicationBuilder.Services.Configure. - Upgrade to .Net 8. - Do not intentionally enable the Configuration-binding source generator. ### Expected behavior Project should build successfully. Configuration-binding source generator should not be enabled. ### Actual behavior Project fails to build with the following error: `BindingExtensions.g.cs(131,71): error CS0104: 'Options' is an ambiguous reference between 'myProject.Options' and 'Microsoft.Extensions.Options.Options'` Configuration-binding source generator appears to be enabled despite it supposedly being disabled by default. ### Regression? _No response_ ### Known Workarounds false in the csproj ### Configuration .Net 8 ### Other information _No response_

Author:	paulguz-datapa
Assignees:	-
Labels:	`area-Extensions-Configuration`
Milestone:	-

[eerhardt]

Is PublishTrimmed set to true in your app? When a web application has PublishTrimmed or PublishAot set to true, the source generators are enabled in .NET 8. The idea is that when you are trimming, the source generators are the only way to guarantee config binding will work after trimming (or AOT).

See https://github.com/dotnet/aspnetcore/issues/48416 and https://github.com/dotnet/sdk/pull/34022/.

However, if your app is a Blazor WASM app, it shouldn't be enabled by default.

https://github.com/dotnet/sdk/blob/601383646e1547c6bc77c3295be63ff3939b0f2e/src/BlazorWasmSdk/Targets/Microsoft.NET.Sdk.BlazorWebAssembly.Current.targets#L24-L25

[tarekgh]

@paulguz-datapa could you please provide a sample project reproduce the issue? or compile your app with /bl and share the produced msbuild logs.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[tarekgh]

Also, https://github.com/dotnet/runtime/pull/94267 maybe fixing the namespace ambiguity too. You may try the 8.0.2 builds from https://github.com/dotnet/installer or when you share a sample project, I can try it too.

CC @eiriktsarpalis @ericstj

[paulguz-datapa]

@eerhardt Yes, we are enabling PublishTrimmed.

@tarekgh There is a sample solutiuon here.

[tarekgh]

Thanks @paulguz-datapa for providing the sample and answering the questions.

Enabling PublishTrimmed will automatically enable the configuration binding source generator. You already know the workaround if needed <EnableConfigurationBindingGenerator>false</EnableConfigurationBindingGenerator>.

For the ambiguity build errors, I have confirmed through your sample it is fixed by https://github.com/dotnet/runtime/pull/94267. This fix is scheduled to be released next month as the first 8.0 servicing release 8.0.1. With the fix, you'll find the generated code changed from something like:

            if (type == typeof(Options))
            {
                var temp = (Options)instance;
                return;
            }

To

            if (type == typeof(global::CBGError.Options))
            {
                var temp = (global::CBGError.Options)instance;
                return;
            }

I am closing the issue but feel free to send any more question if you have any.

[paulguz-datapa]

thanks @tarekgh

@eerhardt PublishTrimmed enabling source generators doesn't seem to be documented (the What's New doc only mentions AOT and there's no sign at the Trimming Options doc either)

[eerhardt]

@captainsafia - do you know of a good place to document this behavior? Also cc @gewarren

We made this change with https://github.com/dotnet/sdk/pull/34022

[captainsafia]

@captainsafia - do you know of a good place to document this behavior? Also cc @gewarren

We made this change with dotnet/sdk#34022

The trimming options doc page referenced by @paulguz-datapa seems as good a place as any.

I opened a docs issue to track this over at https://github.com/dotnet/docs/issues/38555