ActivatorUtilities.CreateInstance se chová konzistentně

Chování ActivatorUtilities.CreateInstance je nyní konzistentnější s CreateFactory(Type, Type[]). Pokud IServiceProviderIsService není přítomen v kontejneru injektáže závislostí (DI), použije se logika CreateInstance. Podle této logiky je povolen pouze jeden konstruktor, který se shoduje se všemi zadanými vstupními parametry.

V obecnějším případě, kdy IServiceProviderIsService existuje, rozhraní CreateInstance API preferuje nejdelší přetížení konstruktoru, které má k dispozici všechny své argumenty. Argumenty mohou být vstupní do rozhraní API, zaregistrovány v kontejneru nebo dostupné z výchozích hodnot v samotném konstruktoru.

Představte si následující definici třídy, která zobrazuje dva konstruktory:

public class A
{
   A(B b, C c, string st = "default string") { }
   A() { }
}

Pro tuto definici třídy a pokud je IServiceProviderIsService přítomno, ActivatorUtilities.CreateInstance<A>(serviceProvider, new C()) vytváří instanci A výběrem prvního konstruktoru, který přebírá B, C a string.

Verze byla představena

.NET 8 Preview 1

Předchozí chování

ActivatorUtilities.CreateInstance v některých případech se neočekávaně chová. Zajistilo se, že všechny požadované instance předané do něj existovaly ve zvoleném konstruktoru. Výběr konstruktoru byl však chybný a nespolehlivý.

Nové chování

CreateInstance se pokusí najít nejdelší konstruktor, který odpovídá všem parametrům na základě chování IServiceProviderIsService.

Poznámka:

Pokud IServiceProviderIsService je nakonfigurován nesprávně nebo neexistuje, CreateInstance může fungovat nesprávně nebo nejednoznačně.

Typ zásadní změny

Tato změna je změna chování.

Důvod změny

Tato změna byla zavedena k opravě chyby, kdy se chování změnilo v závislosti na pořadí definic přetížení konstruktoru.

Pokud se vaše aplikace začne chovat jinak nebo vyvolá výjimku po upgradu na .NET 8, pečlivě prozkoumejte definice konstruktoru pro ovlivněný typ instance. Přečtěte si část Nové chování .

Ovlivněná rozhraní API

Viz také