Delen via


ActivatorUtilities.CreateInstance gedraagt zich consistent

Het gedrag van ActivatorUtilities.CreateInstance is nu consistenter met CreateFactory(Type, Type[]). Wanneer IServiceProviderIsService niet aanwezig is in de container voor afhankelijkheidsinjectie (DI), valt CreateInstance terug op de CreateFactory(Type, Type[]) logica. In die logica mag slechts één constructor overeenkomen met alle opgegeven invoerparameters.

In het meer algemene geval wanneer IServiceProviderIsService aanwezig is, geeft de CreateInstance API de voorkeur aan de langste constructoroverload met alle beschikbare argumenten. De argumenten kunnen worden ingevoerd voor de API, geregistreerd in de container of beschikbaar zijn op basis van standaardwaarden in de constructor zelf.

Houd rekening met de volgende klassedefinitie met twee constructors:

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

Voor deze klassedefinitie en wanneer IServiceProviderIsService aanwezig is, instantieert ActivatorUtilities.CreateInstance<A>(serviceProvider, new C())A door de eerste constructor te kiezen die B, C en string aanneemt.

Geïntroduceerde versie

.NET 8 Preview 1

Vorig gedrag

ActivatorUtilities.CreateInstance gedraagt zich onverwacht in sommige gevallen. Het zorgde ervoor dat alle vereiste instanties die eraan werden doorgegeven, bestonden in de gekozen constructor. De keuze van de constructor was echter vol bugs en onbetrouwbaar.

Nieuw gedrag

CreateInstance probeert de langste constructor te vinden die overeenkomt met alle parameters op basis van het gedrag van IServiceProviderIsService.

Opmerking

Als IServiceProviderIsService onjuist is geconfigureerd of niet bestaat, kan CreateInstance mogelijk onjuist of dubbelzinnig functioneren.

Type van brekende verandering

Deze wijziging is een gedragswijziging.

Reden voor wijziging

Deze wijziging is geïntroduceerd om een fout op te lossen waarbij het gedrag is gewijzigd, afhankelijk van de volgorde van overbelastingsdefinities van constructors.

Als uw app zich anders gedraagt of een uitzondering genereert na de upgrade naar .NET 8, moet u de constructordefinities voor het betrokken exemplaartype zorgvuldig onderzoeken. Raadpleeg de sectie Nieuw gedrag .

Betreffende API's

Zie ook