In früheren Versionen von Ninject.Extensions.Conventions war es ziemlich einfach, ein Verzeichnis nach Assemblys zu durchsuchen, Klassen nach Interface zu filtern und dann alle enthaltenen ninject Module zu laden.Ninject -> Assemblys für passende Interfaces scannen und als Module laden
kernel.Scan(scanner =>
scanner.FromAssembliesInPath(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location))
scanner.AutoLoadModules();
scanner.WhereTypeInheritsFrom<IPlugin>());
public class MyPlugin : NinjectModule, IPlugin {
public override void Load() {
Bind<IRepositoryFromPluginHost>().To<MyPluginImpl>().Named("special");
}
}
aber nachdem ich in letzter Zeit auf die neueste Version aktualisiert, scheint alles weg und ich bin nicht in der Lage zu
- Auto-Lademodule
- Filtertypen von Schnittstellen
Does Hat jemand eine Lösung dafür?
Ja, aber das ist nicht genau das, was ich beabsichtigt habe. In diesem Beispiel werden alle Klassen aus Assemblys in einem bestimmten Pfad geladen, die von einer bestimmten Schnittstelle erben und die Standardschnittstelle binden. Ich möchte jedoch nur Ninject-Module als Plugins von Assemblys laden, in denen die Bindungsanweisungen enthalten sind. – Acrotygma
Sorry, dass ich es falsch verstanden habe. Ich werde prüfen, ob es einen Weg gibt, das zu erreichen. Ninject StandardKernel lädt standardmäßig immer noch'IModule' in Assemblys, die mit'Ninject.Extensions.' beginnen, damit der Code zugänglich ist. – BatteryBackupUnit
Es hat mich so lange gedauert. Ich habe die Antwort aktualisiert, um zu zeigen, wie wir früher mit Plugins umgegangen sind. Wenn Sie nicht möchten, dass die zusätzlichen 'IPlugin'-Bindungen herumschweben, würde ich mit @Eric's Antwort gehen. – BatteryBackupUnit