Unity Container für ASP.NET Web Api PlugIn Architektur nutzen

Hallo zusammen,

ich verwende den Unity Container für meine Web Api Anwendung. Damit Abhängigkeiten der verwendeten ApiController auch aufgelöst werden können, verwende ich die Zusatzkomponenten "Unity.WebApi".

Das funktioniert auch super.

Nun möchte ich aber auch in meinen PlugIn-Controllern diese Funktionalität nutzen.
Also zum Beispiel im Konstruktor eines PlugIn-Controllers eine Abhängigkeit injizieren.
Leider wird dieser Controller nun nicht mehr korrekt geladen, da die WebApi wohl keinen parameterlosen Konstruktor mehr findet. Ist ja auch richtig so.
Ich weiß leider nicht wie ich meine geladenen PlugIn-Controller nun auch Unity in einer Art bekannt mache, wie es "Unity.WebApi" anscheinend mit meinen anderen WebApi-Controllern automatisch gemacht hat.

Weiß jemand was zu tun ist?

Gruß,
wax

Hallo,
bei Castle.Windsor wird der IHttpControllerActivator implementiert, so dass der DIC die Erstellung des Controllers übernimmt. Dependency Injection in ASP.NET Web API with Castle Windsor. Möglicherweise geht das auch für Unity. Dependency Injection in ASP.NET Web API 2

Hi,

HOW TO WEBAPI2 and Unity

Hast du es wie in diesem Beispiel gemacht ? Also eine Unity Config anlegen mit allen Abhängigkeiten und einen DependencyResolver nutzen ?

Unity löst Abhängigkeiten automatisch auf, wenn diese
a.) konfiguriert sind
b.) Unity in dem selben Scope deklariert ist in dem es konfiguriert wurde.

Welche Fehlermeldungen bekommst du und ein wenig Code bitte, um zu sehen wie du vor gegangen bist

Grüße

Genau so wie in diesem Beispiel habe ich es gemacht. Ich bin also den Weg über einen eigenen IDependencyResolver gegangen.

Um meine PlugIns zu laden habe ich einen eigenen AssemblyResolver erstellt. Das funktioniert wie gesagt auch solange wie ich in den PlugIns parameterlose Konstruktoren verwende.

Sobald ich in meinen PlugIn-WebApi-Controllern einen Parameter im Konstruktor nutze, wird dieser Controller garnicht mehr geladen. Also wird seine Route auch nicht mehr bedient.

Gruß,
wax

Damit man wenig Aufwand bei der ASP.NET Aktualisierung auf Core 1 hat, sollte man schon mit Unity arbeiten.
In Core 1 gibt es einen eingebauten DI, der sich an Unity orientiert.

Das mit dem Konstruktor kann ich iwie nicht nachvollziehen.
Wir haben das auch so gemacht und hatten die Probleme nicht. Wir haben aber auch Unity.WebApi nicht verwendet.

Im Großen und Ganzen rufe ich diese Config-Methode, welche ich am Anfang, nachdem der UnityContainer erstellt und initialisiert wurde, in der Global.asax auf:

public static class UnityConfig
{

    /// <summary>
    /// Registers the components.
    /// </summary>
    public static void RegisterComponents()
    {            
        // register all your components with the container here
        // it is NOT necessary to register your controllers
        GlobalConfiguration.Configuration.DependencyResolver = new UnityResolver(Global.Container);
    }
}

Später im Code lade ich die Assemblies, in denen PlugIn-ApiController existieren.
Ich kann im debugger sehen, wie meine "UnityResolver" Klasse für jede Anfrage verwendet wird.
Nur halt nicht für meine PlugIn-Controller. Hier ist mal ein Beispiel PlugIn-Controller:

public class PlugInController : PlugInBaseController
{
    IMyInterface _instance;

    public PlugInController(IMyInterface instance)
    {            
       
        _instance = instance;
    }
}

"PlugInBaseController" erbt von "BaseController" und dieser wiederum von "ApiController".

Gruß,
wax

Bist du denn sicher, dass

IMyInterface 

richtig registriert ist ?

Ja bin ich. Ich glaube ich weiß wo der Knackpunkt ist....

Um mir von den PlugIns zusätzliche Informationen zu holen habe ich bisher mittels Activator eine Instanz erstellt. Das hat so lange funktioniert wie das Plugin einen parameterlosen Konstruktor hatte. Jetzt wird alles plötzlich ganz klar. Ich könnte mir eine Instanz vom parameterlosen Konstruktor erstellen lassen und dann mittels UnityContainer.BuildUp die benötigten Abhängigkeiten injizieren. Mittels PropertyInjection.

Gruß,
Wax

===

Bzw. ich kann auch Unity direkt "resolven" lassen und ganz auf Activator.CreateInstance verzichten.