从DbContext中选择时出现AmbiguousMatchException

时间:2018-07-30 19:05:55

标签: c# entity-framework-core ambiguous

我已经看到了很多有关如何调试在更新或向上下文中添加记录时或在方法有多个重载时遇到的AmbiguousMatchException问题的问题,但是到目前为止,关于何时发现的问题我一无所获从上下文中选择

假设这是我的课程:

public class Foo
{
    public decimal IdNumber {get; set;}

    //...
}

以及映射和上下文:

public class FoosMapping : EntityTypeConfigurationBase /*custom class*/, IEntityTypeConfiguration<Foo>
{
    public void Configure(EntityTypeBuilder<Foo> builder)
    {
        //Table
        builder.ToTable("Foos");

        //Key
        builder.HasKey(key => new {key.IdNumber}).HasName("FoosPk");

        //Fields
        PropertyBuilder<decimal> idField = builder.Property(x => x.IdNumber);
        idField.HasColumnName("IdNumber");
        if (this.ActiveProvider.IndexOf("SqlServer", StringComparison.InvariantCultureIgnoreCase) >= 0)
            idField.HasColumnType("numeric(6,0)");
        //...
    }
}
/***************************************************************************/
public class FooContext
{
    public DbSet<Foo> Foos {get; set;}

    //...
}

现在,我有一个读者类,应该根据它的Foo来选择一个IdNumber。读者可以直接调用this.Context.Foos.SingleOrDefault()来做到这一点,但是相反,它开始给了我AmbiguousMatchException。我什至像这样爆发出来...

20: Foo[] foos = this.Context.Foos.ToArray();
21: Foo result = foos.SingleOrDefault(x => x.IdNumber == idNumber);

...,并且初始化数组数组变量时会出现异常。文本Foos仅在上述三个类,以及writer类和适配器类中找到。 Foo类仅在这三个文件和Autofac绑定中被引用。

我的问题是映射中的idField,还是DB表也称为"Foos"还是其他东西?

编辑:关于异常的堆栈跟踪:

"   at System.RuntimeType.GetMethodImpl(String name, BindingFlags bindingAttr, Binder binder, CallingConventions callConv, Type[] types, ParameterModifier[] modifiers)"

调用堆栈的顶部:

System.Core.dll!System.Linq.Buffer<MyProject.Data.Foo>.Buffer(System.Collections.Generic.IEnumerable<MyProject.Data.Foo> source)

System.Core.dll!System.Linq.Enumerable.ToArray<MyProject.Data.Foo>(System.Collections.Generic.IEnumerable<MyProject.Data.Foo> source)

> MyProject.Entity.dll!MyProject.Entity.Readers.FooReader.Read(decimal idNumber) Line 20

1 个答案:

答案 0 :(得分:0)

对于将来遇到类似问题且无法使用其他解决方案的用户,此问题是由于安装了新版本的EF Core导致的,该版本无法与我们现有的依赖项注入框架很好地配合使用。 Powers-That-Be决定暂时回滚到较早的EF Core版本,并且现在一切正常。