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

Junjun-zhao · 2022-11-25T07:03:28Z

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

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

Minimal Repro sample:

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

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

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();

Build and launch app.

Exceptions (if any)

Actual Result:
Launch failed with below exception:

Findings:

Upgrading Quartz.Extensions.DependencyInjection package from 3.3.3 to 3.5.0 (latest released) will fix this exception.
We think related to this assembly: Microsoft.Extensions.Configuration.Binder.dll
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

The text was updated successfully, but these errors were encountered:

ghost · 2022-11-28T23:37:06Z

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

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

Minimal Repro sample:

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

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

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();

Build and launch app.

Exceptions (if any)

Actual Result:
Launch failed with below exception:

Findings:

Upgrading Quartz.Extensions.DependencyInjection package from 3.3.3 to 3.5.0 (latest released) will fix this exception.
We think related to this assembly: Microsoft.Extensions.Configuration.Binder.dll
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 · 2022-11-28T23:37:39Z

@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 · 2022-11-28T23:52:28Z

@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 · 2022-11-29T01:13:58Z

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 · 2022-11-29T01:27:08Z

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

Junjun-zhao · 2022-11-29T02:11:41Z

@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 · 2022-11-29T02:24:23Z

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

tarekgh · 2022-11-29T03:33:38Z

@halter73 I have created the PR #78946. I appreciate if you can look. Thanks!

tarekgh · 2022-11-30T21:40:57Z

This is fixed for servicing through the PR #79019

Junjun-zhao · 2022-12-06T09:18:53Z

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

contione · 2022-12-26T05:43:02Z

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 · 2022-12-27T19:45:00Z

@contione the fix is not released yet.

adityamandaleeka added the investigate label Nov 28, 2022

adityamandaleeka transferred this issue from dotnet/aspnetcore Nov 28, 2022

dotnet-issue-labeler bot added the area-Extensions-Configuration label Nov 28, 2022

ghost added the untriaged New issue has not been triaged by the area owner label Nov 28, 2022

tarekgh added this to the 7.0.x milestone Nov 28, 2022

ghost removed the untriaged New issue has not been triaged by the area owner label Nov 28, 2022

tarekgh self-assigned this Nov 29, 2022

tarekgh added regression-from-last-release and removed investigate labels Nov 29, 2022

tarekgh modified the milestones: 7.0.x, 7.0.2 Nov 29, 2022

tarekgh mentioned this issue Nov 29, 2022

Fix configuration binding with types implementing IDictionary<,> #78946

Merged

tarekgh mentioned this issue Nov 30, 2022

[release/7.0] Fix configuration binding with types implementing IDictionary<,> #79019

Merged

ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Nov 30, 2022

tarekgh closed this as completed Nov 30, 2022

ghost locked as resolved and limited conversation to collaborators Jan 27, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Junjun-zhao commented Nov 25, 2022 •

edited

Loading

ghost commented Nov 28, 2022

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version

Anything else?

halter73 commented Nov 28, 2022

tarekgh commented Nov 28, 2022 •

edited

Loading

halter73 commented Nov 29, 2022 •

edited

Loading

tarekgh commented Nov 29, 2022

Junjun-zhao commented Nov 29, 2022

tarekgh commented Nov 29, 2022

tarekgh commented Nov 29, 2022

tarekgh commented Nov 30, 2022

Junjun-zhao commented Dec 6, 2022

contione commented Dec 26, 2022

tarekgh commented Dec 27, 2022

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

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

Comments

Junjun-zhao commented Nov 25, 2022 • edited Loading

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version

Anything else?

ghost commented Nov 28, 2022

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version

Anything else?

halter73 commented Nov 28, 2022

tarekgh commented Nov 28, 2022 • edited Loading

halter73 commented Nov 29, 2022 • edited Loading

tarekgh commented Nov 29, 2022

Junjun-zhao commented Nov 29, 2022

tarekgh commented Nov 29, 2022

tarekgh commented Nov 29, 2022

tarekgh commented Nov 30, 2022

Junjun-zhao commented Dec 6, 2022

contione commented Dec 26, 2022

tarekgh commented Dec 27, 2022

Junjun-zhao commented Nov 25, 2022 •

edited

Loading

tarekgh commented Nov 28, 2022 •

edited

Loading

halter73 commented Nov 29, 2022 •

edited

Loading