Partage via

ActivatorUtilities.CreateInstance se comporte de manière cohérente

  • Article

Le comportement de ActivatorUtilities.CreateInstance est désormais plus cohérent avec CreateFactory(Type, Type[]). Quand IServiceProviderIsService n’est pas présent dans le conteneur d’injection de dépendances (DI), CreateInstance revient à la logique CreateFactory(Type, Type[]). Dans cette logique, un seul constructeur est autorisé à correspondre à tous les paramètres d’entrée fournis.

Dans le cas plus général où IServiceProviderIsService est présent, l’API CreateInstance préfère le constructeur avec la plus lourde surcharge avec tous ses arguments disponibles. Les arguments peuvent être entrés dans l’API, inscrits dans le conteneur ou disponibles à partir de valeurs par défaut dans le constructeur lui-même.

Observez la définition de classe suivante montrant deux constructeurs :

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

Pour cette définition de classe et quand IServiceProviderIsService est présent, ActivatorUtilities.CreateInstance<A>(serviceProvider, new C()) instancie A en choisissant le premier constructeur qui prend B, C et string.

Version introduite

.NET 8 Preview 1

Comportement précédent

ActivatorUtilities.CreateInstance se sont comportés de manière inattendue dans certains cas. Il s’est assuré que toutes les instances requises qui lui ont été transmises existaient dans le constructeur choisi. Toutefois, la sélection du constructeur comportait des bogues et était peu fiable.

Nouveau comportement

CreateInstance recherche le constructeur avec la plus lourde surcharge et qui correspond à tous les paramètres en fonction du comportement de IServiceProviderIsService.

Notes

Si IServiceProviderIsService est configuré incorrectement ou n’existe pas, CreateInstance peut fonctionner de manière incorrecte ou ambiguë.

Type de changement cassant

Ce changement est un changement de comportement.

Raison du changement

Ce changement a été introduit pour corriger un bogue entraînant un changement du comportement en fonction de l’ordre des définitions de surcharge du constructeur.

Si votre application commence à se comporter différemment ou à lever une exception après la mise à niveau vers .NET 8, examinez attentivement les définitions du constructeur pour le type d’instance affecté. Reportez-vous à la section Nouveau comportement.

API affectées

Voir aussi