Ich habe einen Branch , der dies in unserem Container implementiert und Spezifikationstests hinzufügt, aber ich habe einige Bedenken:

1. Wir verlangen nicht, dass IServiceProvider IDisposable in der Spezifikation sein muss, aber das Hinzufügen dieser Tests erzwingt dies. Weder die Autofac- noch die StructureMap-Implementierung von IServiceProvider ist IDisposable
2. Autofac tut dies in der richtigen Reihenfolge, aber StructureMap verteilt die Dienste in der Reihenfolge der Erstellung.

@khellang @nblumhardt was

Danke für das Einschleifen! Dies klingt wie ein weiterer Fall, in dem Annahmen im Framework zu Problemen bei einigen Containerintegrationen führen können.

Die Entsorgung in umgekehrter Reihenfolge ist notwendig, um einige Komponentengraphen korrekt zu löschen, zB wenn A : IDisposable sich bei der Erstellung mit B : IDisposable "registriert" und bei der Entsorgung "unregistriert", aber:

• Das Framework könnte diese Art von Objektgraphen vermeiden, oder
• Einige zusätzliche Codes könnten hinzugefügt werden, zB Mediator-Objekte, damit die Szenarien unabhängig von der Entsorgungsreihenfolge funktionieren.

Wenn Benutzer eine Forward-Order-Entsorgung wünschen, sollten sie sich darauf verlassen können, indem sie einen Container auswählen, der sie implementiert - und umgekehrt. Persönlich denke ich, dass die umgekehrte Reihenfolge der _richtige_ Weg ist, aber es ist sehr unwahrscheinlich, dass mir alle zustimmen ;-)

433 ist eine Diskussion in diese Richtung - die Entsorgungsreihenfolge wäre ein guter Punkt, um die Zusammenfassung auf diesem Ticket hinzuzufügen, denke ich.

Behoben durch https://github.com/aspnet/DependencyInjection/pull/505