[dotnet-sdk-7.0.101] System.Reflection.AmbiguousMatchException: 'Ambiguous match found.'

[Junjun-zhao]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

When launch the aspnet core app mixcore against .NET 7.0.101 runtime, it failed with exception.

Application Name: mixcore OS: Windows 10 21H2 CPU: X64 .NET Build Number: dotnet-sdk-7.0.101

Verify Scenarios: 1). Windows10 21H2 x64+dotnet-sdk-7.0.101: Fail 2). Windows10 21H2 x64+dotnet-sdk-7.0.100: Pass

App and App Source checking at : https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1687533 Github Link: https://github.com/mixcore/mix.core

Expected Behavior

App will launch successful.

Steps To Reproduce

This is .net6.0 app, but we are running it on 7.0, machine only have 7.0 installed, and DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX=2, so it runs on 7.0

1. Copy mixcore app to local machine.
2. Launch mixcore app with command "dotnet mixcore.dll --urls=https://localhost:5001"

Minimal Repro sample:

1. Create a .NET 7.0 Asp.NET Core app.
2. Install these packages from Nuget (both v3.3): Quartz.AspNetCore v3.3.3 and Quartz.Extensions.DependencyInjection v3.3.3
3. Add Quartz configuration in appsettings.json.

   "Logging": {
   "LogLevel": {
     "Default": "Information",
     "Microsoft.AspNetCore": "Warning"
   }
   },
   "AllowedHosts": "*",
   "Quartz": {
   "quartz.scheduler.instanceName": "Mixcore Cms Scheduler"
   }
   }

4. Add Quartz service in Program.cs file:

   builder.Services.AddRazorPages();
   builder.Services.Configure<QuartzOptions>(builder.Configuration.GetSection("Quartz"));
   builder.Services.AddQuartz(q =>
   {
   // base Quartz scheduler, job and trigger configuration
   });
   // ASP.NET Core hosting
   builder.Services.AddQuartzServer(options =>
   {
   // when shutting down we want jobs to complete gracefully
   options.WaitForJobsToComplete = true;
   });
   var app = builder.Build();

5. Build and launch app.

Exceptions (if any)

Actual Result: Launch failed with below exception:

Findings:

1. Upgrading Quartz.Extensions.DependencyInjection package from 3.3.3 to 3.5.0 (latest released) will fix this exception.
2. We think related to this assembly: Microsoft.Extensions.Configuration.Binder.dll
3. In Quartz.Extensions.DependencyInjection 3.5.0 release note, they change QuartzOptions to inherit from Dictionary<string, string> instead of NameValueCollection to fix Microsoft.Extensions.Configuration 7 RC integration issue. (Microsoft DI integration does not work with Microsoft.Extensions.Hosting RC1 · Issue dotnet/aspnetcore#1748 · quartznet/quartznet (github.com) StackTrace:

   at System.RuntimeType.GetPropertyImpl(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
   at System.Type.GetProperty(String name, BindingFlags bindingAttr)
   at Microsoft.Extensions.Configuration.ConfigurationBinder.BindConcreteDictionary(Object dictionary, Type dictionaryType, IConfiguration config, BinderOptions options)
   at Microsoft.Extensions.Configuration.ConfigurationBinder.BindInstance(Type type, BindingPoint bindingPoint, IConfiguration config, BinderOptions options)
   at Microsoft.Extensions.Options.OptionsFactory`1.Create(String name)
   at Microsoft.Extensions.Options.UnnamedOptionsManager`1.get_Value()
   at Quartz.ServiceCollectionSchedulerFactory.<GetScheduler>d__6.MoveNext()
   at Quartz.QuartzHostedService.<StartAsync>d__4.MoveNext()
   at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>d__12.MoveNext()
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.<RunAsync>d__4.MoveNext()
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.<RunAsync>d__4.MoveNext()
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
   at Program.<Main>$(String[] args) in C:\Users\v-weiwc\source\repos\WebApplication2\WebApplication2\Program.cs:line 39m.cs:line 39

   .NET Version

dotnet-sdk-7.0.101

Anything else?

dotnet --info

.NET SDK:
Version:   7.0.101
Commit:    e54f57cd94

Runtime Environment:
OS Name:     Windows
OS Version:  10.0.22621
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\7.0.101\ 

Host:
  Version:      7.0.1
  Architecture: x64
  Commit:       97203d38ba 

.NET SDKs installed:
  7.0.101 [C:\Program Files\dotnet\sdk] 

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

@dotnet-actwx-bot @dotnet/compat

[ghost]

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

Issue Details

---

### Is there an existing issue for this? - [X] I have searched the existing issues ### Describe the bug **When launch the aspnet core app mixcore against .NET 7.0.101 runtime, it failed with exception.** **Application Name**: mixcore **OS**: Windows 10 21H2 **CPU**: X64 **.NET Build Number**: dotnet-sdk-7.0.101 **Verify Scenarios:** 1). Windows10 21H2 x64+dotnet-sdk-7.0.101: Fail 2). Windows10 21H2 x64+dotnet-sdk-7.0.100: Pass **App and App Source checking at** : https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1687533 **Github Link**: https://github.com/mixcore/mix.core ### Expected Behavior App will launch successful. ### Steps To Reproduce **This is .net6.0 app, but we are running it on 7.0, machine only have 7.0 installed, and DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX=2, so it runs on 7.0** 1. Copy mixcore app to local machine. 2. Launch mixcore app with command "dotnet mixcore.dll --urls=https://localhost:5001" **Minimal Repro sample:** 1. Create a .NET 7.0 Asp.NET Core app. 2. Install these packages from Nuget (both v3.3): Quartz.AspNetCore v3.3.3 and Quartz.Extensions.DependencyInjection v3.3.3 3. Add Quartz configuration in appsettings.json. ``` "Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" } }, "AllowedHosts": "*", "Quartz": { "quartz.scheduler.instanceName": "Mixcore Cms Scheduler" } } ``` 4. Add Quartz service in Program.cs file: ``` builder.Services.AddRazorPages(); builder.Services.Configure(builder.Configuration.GetSection("Quartz")); builder.Services.AddQuartz(q => { // base Quartz scheduler, job and trigger configuration }); // ASP.NET Core hosting builder.Services.AddQuartzServer(options => { // when shutting down we want jobs to complete gracefully options.WaitForJobsToComplete = true; }); var app = builder.Build(); ``` 5. Build and launch app. ### Exceptions (if any) **Actual Result:** Launch failed with below exception:  **Findings:** 1. Upgrading Quartz.Extensions.DependencyInjection package from 3.3.3 to 3.5.0 (latest released) will fix this exception. 2. We think related to this assembly: Microsoft.Extensions.Configuration.Binder.dll 3. In Quartz.Extensions.DependencyInjection 3.5.0 release note, they change QuartzOptions to inherit from Dictionary instead of NameValueCollection to fix Microsoft.Extensions.Configuration 7 RC integration issue. ([Microsoft DI integration does not work with Microsoft.Extensions.Hosting RC1 · Issue dotnet/aspnetcore#1748 · quartznet/quartznet (github.com)](https://github.com/quartznet/quartznet/issues/1748) **StackTrace:** ``` at System.RuntimeType.GetPropertyImpl(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers) at System.Type.GetProperty(String name, BindingFlags bindingAttr) at Microsoft.Extensions.Configuration.ConfigurationBinder.BindConcreteDictionary(Object dictionary, Type dictionaryType, IConfiguration config, BinderOptions options) at Microsoft.Extensions.Configuration.ConfigurationBinder.BindInstance(Type type, BindingPoint bindingPoint, IConfiguration config, BinderOptions options) at Microsoft.Extensions.Options.OptionsFactory`1.Create(String name) at Microsoft.Extensions.Options.UnnamedOptionsManager`1.get_Value() at Quartz.ServiceCollectionSchedulerFactory.d__6.MoveNext() at Quartz.QuartzHostedService.d__4.MoveNext() at Microsoft.Extensions.Hosting.Internal.Host.d__12.MoveNext() at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.d__4.MoveNext() at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.d__4.MoveNext() at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host) at Program.

$(String[] args) in C:\Users\v-weiwc\source\repos\WebApplication2\WebApplication2\Program.cs:line 39m.cs:line 39 ``` ### .NET Version dotnet-sdk-7.0.101 ### Anything else? **dotnet --info** ``` .NET SDK: Version: 7.0.101 Commit: e54f57cd94 Runtime Environment: OS Name: Windows OS Version: 10.0.22621 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\7.0.101\ Host: Version: 7.0.1 Architecture: x64 Commit: 97203d38ba .NET SDKs installed: 7.0.101 [C:\Program Files\dotnet\sdk] .NET runtimes installed: Microsoft.AspNetCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] ``` @dotnet-actwx-bot @dotnet/compat

Author:	Junjun-zhao
Assignees:	-
Labels:	`area-Extensions-Configuration`, `investigate`
Milestone:	-

[halter73]

@SteveDunn I haven't had a chance to look at the repro yet, but is it possible this was related to the immutable type changes in 7.0?

[tarekgh]

@Junjun-zhao I am noticing you are using SDK 7.0.1 which is not released yet. do you see the issue on 7.0.0? I am asking because I suspect this can be from the change https://github.com/dotnet/runtime/pull/78118.

[halter73]

In 7.0.0, we added BindConcreteDictionary which looked for TryGetValue and Item on typeof(Dictionary<,>).MakeGenericType(keyType, valueType) rather than on a potentially user-defined type to avoid the possibility of this kind of ambiguity.

I see that #78118 changes the logic to now pass potentially user-defined IDictionary<,> implementations to BindConcreteDictionary which now creates the possibility of this ambiguity starting in 7.0.1. Not doing so seems incredibly risky in a patch. I don't think this kind of ambiguity was ever possible before.

If we're trying to revert to 6.x behavior, we should use FindOpenGenericInterface to get TryGetValue and Item off the interface rather than the potentially user-defined type. This is how we do it in release/6.0.

https://github.com/dotnet/runtime/blob/77f4e9981ccd835eaa2866af22cdc33dd8237508/src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs#L381-L385

[tarekgh]

@halter73 right, that what I was suspecting too. I agree with your suggestion on how to fix it.

[Junjun-zhao]

@tarekgh It did not repro on 7.0.0 release(Windows10 21H2 x64+dotnet-sdk-7.0.100: Pass). Is this a blocker for 7.0.1? Will this issue be fixed in 7.0.1?

[tarekgh]

This confirms our theory. I'll work on the fix. Thanks @Junjun-zhao for reporting and confirming the issue.

[tarekgh]

@halter73 I have created the PR https://github.com/dotnet/runtime/pull/78946. I appreciate if you can look. Thanks!

[tarekgh]

This is fixed for servicing through the PR https://github.com/dotnet/runtime/pull/79019

[Junjun-zhao]

Verified and this issue has been fixed on dotnet-7.0.102-servicing.22602.11.

[contione]

At present, the latest official docker image does not seem to work, and such problems still occur.

mcr.microsoft.com/dotnet/aspnet:7.0

[tarekgh]

@contione the fix is not released yet.