Ho visto molte domande su come eseguire il debug di una AmbiguousMatchException rilevata durante l'aggiornamento o l'aggiunta di un record a un contesto, o quando ci sono più sovraccarichi di un metodo, ma non ho trovato nulla finora sui problemi riscontrati quando si seleziona da un contesto.
Supponiamo che questa sia la mia classe:
public class Foo
{
public decimal IdNumber {get; set;}
//...
}
E la mappatura e il contesto:
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;}
//...
}
Ora, ho una classe di lettori che dovrebbe scegliere un Foo
basato sul suo IdNumber
. Questo dovrebbe essere possibile con una semplice chiamata nel lettore a this.Context.Foos.SingleOrDefault()
, ma invece ha iniziato a darmi un AmbiguousMatchException. L'ho persino rotto in questo modo ...
20: Foo[] foos = this.Context.Foos.ToArray();
21: Foo result = foos.SingleOrDefault(x => x.IdNumber == idNumber);
... e compare l'eccezione durante l'inizializzazione della variabile dell'array. Il testo Foos
trova solo nelle tre classi sopra menzionate, oltre a una classe writer e una classe adapter. La classe Foo
viene citata solo in questi tre file e in un binding di Autofac.
Il mio problema è l' idField
nella mappatura, il fatto che la tabella DB sia chiamata anche "Foos"
o qualcos'altro?
MODIFICA: la traccia dello stack nell'eccezione:
" at System.RuntimeType.GetMethodImpl(String name, BindingFlags bindingAttr, Binder binder, CallingConventions callConv, Type[] types, ParameterModifier[] modifiers)"
La cima della pila di chiamate:
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
Per gli utenti futuri che incontrano problemi simili e per i quali altre soluzioni non funzionano, questo problema è dovuto all'installazione di una nuova versione di EF Core, che non stava giocando bene con il nostro framework di distribuzione delle dipendenze esistente. The Powers-That-Be ha deciso di tornare a una versione più vecchia di EF Core per il momento, e tutto funziona ora.