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

[Junjun-zhao]

Is there an existing issue for this?

• 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

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?

• 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

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 #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.

runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs

Lines 381 to 385 in 77f4e99

	Type collectionInterface = FindOpenGenericInterface(typeof(IDictionary<,>), type);
	if (collectionInterface != null)
	{
	BindDictionary(instance, collectionInterface, config, options);
	}

[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.