C # método que se ejecuta después del montaje es cargado

Question

escribo alguna clase C # libary y quiero utilizar Ninject para proporcionar la inyección de dependencias para mis clases. ¿Es posible que libary clase para declarar un cierto código (método) que se ejecuta en cada FIME se carga el libary clase. Necesito esto para definir fijaciones para Ninject.

Answer 1

He utilizado Ninject un poco en los últimos 9 meses. Suena como lo que hay que hacer es "cargar" los módulos que existen en su libray en el núcleo Ninject con el fin de registrar las fijaciones.

No estoy seguro de si está utilizando 1.x Ninject o la versión beta 2.0. Las dos versiones realizan las cosas de forma ligeramente diferente, aunque conceptualmente, que son los mismos. Yo me quedo con la versión 1.x para esta discusión. La otra pieza de información que no sé es si su programa principal es una instancia del kernel Ninject y su biblioteca es simplemente agregar fijaciones a ese núcleo, o si su propia biblioteca contiene el núcleo y los enlaces. Estoy asumiendo que es necesario agregar fijaciones de la biblioteca a cualquier núcleo de Ninject existente en el conjunto principal. Por último, voy a hacer la suposición de que está cargando dinámicamente esta biblioteca y que no es estática vinculada al programa principal.

Lo primero que debe hacer es definir un módulo ninject en su biblioteca en la que se registre todas sus fijaciones - es posible que ya haya hecho esto, pero vale la pena mencionar. Por ejemplo:

public class MyLibraryModule : StandardModule {
  public override void Load() {
    Bind<IMyService>()
      .To<ServiceImpl>();
    // ... more bindings ...
  }
}

Ahora que las fijaciones están contenidas dentro de un módulo de Ninject, puede registrarse fácilmente cuando la carga de su montaje. La idea es que una vez que se carga el ensamblaje, puede analizarlo en busca de todo tipo que se derivan de StandardModule. Una vez que tenga este tipo, puede cargarlos en el kernel.

// Somewhere, you define the kernel...
var kernel = new StandardKernel();

// ... then elsewhere, load your library and load the modules in it ...

var myLib = Assembly.Load("MyLibrary");
var stdModuleTypes = myLib
                       .GetExportedTypes()
                       .Where(t => typeof(StandardModule).IsAssignableFrom(t));


foreach (Type type in stdModuleTypes) {
  kernel.Load((StandardModule)Activator.CreateInstance(type));
}

Una cosa a destacar, se puede generalizar el código anterior más para cargar múltiples bibliotecas y registrar varios tipos. Además, como he mencionado anteriormente, Ninject 2 tiene este tipo de capacidad incorporado - que en realidad tiene la capacidad de escanear directorios, asambleas de carga y registro de módulos. Muy fresco.

Si su situación es ligeramente diferente a lo que he descrito, los mismos principios pueden ser adaptados probable.

Answer 2

Parece que usted está buscando el equivalente de DllMain C ++ 's. No hay manera de hacer esto en C #.

Puede darnos algo más de información acerca de su situación y por qué necesita para ejecutar código en una función DllMain estilo?

La definición de un constructor estático en un tipo no resuelve este problema. Un constructor de tipo estático sólo se garantiza para funcionar antes de que el tipo en sí se utiliza de ninguna manera. Se puede definir un constructor estático, utilice otro tipo de código dentro de la DLL que no accede al tipo y es constructor nunca va a funcionar.

Answer 3

¿Has probado el evento AppDomain.AssemblyLoad? Se dispara después de un conjunto ha sido cargado.

AppDomain.CurrentDomain.AssemblyLoad += (s, e) =>
{
    Assembly justLoaded = e.LoadedAssembly;
    // ... etc.
};

Answer 4

Se puede controlar el código de cliente? Si es así, en lugar de tratar de hacer magia cuando se carga el montaje, me gustaría ir para la implementación de una sola clase como Registro, que hace las ataduras, la implementación de un IRegistry interfaz. A continuación, durante la carga se puede buscar la implementación de IRegistry en su montaje y fuego métodos necesarios.

También puede tener atributos en sus clases:

[Component(Implements=typeof(IMyDependency)]

buscar estos atributos y cargarlos al contenedor en el lado del cliente.

O bien, puede echar un vistazo a MEF que es una biblioteca para este tipo de situaciones.

Answer 5

Por lo que yo sé la respuesta es no .Como entiendo que desea configurar su contenedor COI en la biblioteca de clases y si ese es el caso que no es una buena idea hacer that.If a definir sus fijaciones en la biblioteca de clase, entonces ¿cuál es el uso de la inyección de dependencia? usamos la inyección de dependencias para que podamos inyectar dependencias en tiempo de ejecución, entonces podemos inyectar diferentes objetos en diferentes scenarios.Although el mejor lugar para configurar un contenedor IoC es la puesta en marcha de su aplicación (desde un contenedor IoC es como una columna vertebral para una aplicación :)) pero debe ser colocado a una rutina de carga que es responsable de iniciar las aplicaciones simples application.In puede ser el método principal.