Fluido NHibernate 1.2 - El miembro invocado no es compatible con un ensamblaje dinámico

He actualizado mi Fluent NHibenate a 1.2 porque he actualizado NHibenate a la versión 3.0. Esto fue a su vez porque uso ANTLR en mi proyecto y tuve problemas de compatibilidad entre las versiones de ANTLR. Ahora recibo este error al crear asignaciones como parte de la llamada Fluently.Configure() que no recibí anteriormente con la versión 1.0.X.X usando los mismos ensamblajes. Estoy desarrollando en C# .NET 3.5 en VS2008.Fluido NHibernate 1.2 - El miembro invocado no es compatible con un ensamblaje dinámico

El error es "El miembro invocado no es compatible con un ensamblaje dinámico".

public static ISessionFactory GetFactory() 
    { 
     if (_factory == null) 
     { 
      Assembly assembly = Assembly.Load("BigFoot.Infrastructure"); 

      IApplicationContext springContainer = ContextRegistry.GetContext(); 
      IDbProvider provider = (IDbProvider)springContainer.GetObject("DbProvider"); 

      string connection = provider.ConnectionString; 

      if (connection.Length > 0) 
      { 

       _factory = Fluently.Configure() 
        .Database(MsSqlConfiguration.MsSql2008.ConnectionString(connection)) 
        .Mappings(m => 
         { 
          m.FluentMappings.AddFromAssembly(assembly); 
          m.HbmMappings.AddFromAssembly(assembly); 
         }) 

        .BuildSessionFactory(); 
      } 
     } 

     return _factory; 
    }

Fuente

2011-02-15 Marc

por favor, publique la traza de la pila completa –

sí, y si dice qué clase se bloqueó, por favor, publique el código para eso también – kelloti

Creo que se refiere a v1.1.1.694. No hay FNH 1.2. – Yogesh

Acabo de pasar toda la mañana en exactamente el mismo problema.

Intenté todo, pero al final lo que lo solucionó fue eliminar todas mis carpetas bin. De hecho, borré mi proyecto y luego actualicé la última versión del repositorio (las carpetas bin no deberían estar marcadas), luego construí y ejecuté el proyecto nuevamente. En algún lugar, de alguna manera, algo cambió, lo que significaba que nHibernate no podía encontrar la información de ensamblaje para log4net. ¡Supongo que tiene algo que ver con una configuración incorrecta en el directorio de destino que una limpieza/reconstrucción no resuelve!

Fuente

2011-02-16 14:15:09

Maldición cuando hice una limpieza y luego una compilación eliminó el problema. Odio cuando esto sucede. Gracias Chris por la sugerencia. – Mark

No hay problema, me alegro de poder ayudar –

Solución limpia -> solución de compilación no lo hizo por mí. Ignorar la excepción parece no causar problemas. –

Para aquellos que enfrentarán el problema de nuevo. Esta excepción es un comportamiento normal, porque no es un comportamiento no controlado. La única razón por la que lo ve es que visual studio está configurado para que vea todas las excepciones (manejadas y no controladas) y 'depurar solo mi código' está deshabilitado. Por lo tanto, puede ignorar la excepción y presionar Continuar cuando se detecta o configurar Visual Studio para que no muestre tales excepciones.

Fuente

2011-12-04 06:27:42 StuffHappens

Hoy recibí una llamada de otro desarrollador de mi equipo en relación con una excepción NotSupportedException lanzada desde una llamada a 'Fluently.Configure()'. Aparte de detener Visual Studio para informar la excepción, no hubo ningún comportamiento aberrante. Tenía la opción "Habilitar simplemente mi código" desactivada. También lo desactivé y vi la excepción. Pero NHibernate estaba funcionando bien. Le dije que se asegurara de que se revisara la opción y que no me preocupara porque NHibernate parece estar manejando adecuadamente esta excepción. –

También recibí una excepción que decía "El miembro invocado no es compatible con un ensamblaje dinámico". y me causó un dolor de cabeza encontrar su causa en mi caso.

La razón mencionada en la respuesta de @StuffHappens también fue válida para mí: también había revisado la casilla "Lanzada" para "Excepciones de Common Language Runtime" en el cuadro de diálogo Depurar-> Excepciones. Pero, también he desmarcado Herramientas-> Opciones-> Depuración -> "Habilitar solo mi código (solo administrado)". De hecho, no esperaba que tales excepciones aparecieran durante el degugging cuando lo hice.

Además de la excepción antes mencionada, también vi

un MissingManifestResourceException de DevExpress quejarse de algún elemento SkinInfoBlob.resources no estar presente en una DLL que contiene un aspecto personalizado
FileNotFoundExceptions diferentes quejándose supuestamente desaparecidos *. Conjuntos de XMLSerializers que tienen la misma versión que el ensamblado donde reside un tipo deseado (no solo para nuestros ensambles, sino también para NHibernate.XmlSerializers)
a NotSupportedException de Spring.Net que intenta resolver algún objeto de N Hibernate indicando "El miembro invocado no es compatible con un ensamblaje dinámico". (O "Der aufgerufene miembro wird in einer unterstützt dynamischen nicht Asamblea." En alemán)
FormatException cuando se trata de símbolos TatukGIS indica (o "Die Eingabezeichenfolge hat das Falsche formato." En alemán)

I marcó la casilla "Habilitar solo mi código (solo administrado)" y todas las misteriosas excepciones desaparecieron.

Espero que esto ayude a alguien a salir de este escollo.

Fuente

2014-02-14 12:56:38

Obtuve el mismo error al cargar un archivo sql para usarlo en el código de dapper, establecí la acción de compilación en "Recurso incrustado" y.El ensamblado NET fue capaz de cargarlo.

Fuente

2016-06-16 14:37:05 user3266757

Fluido NHibernate 1.2 - El miembro invocado no es compatible con un ensamblaje dinámico

Respuesta

Cuestiones relacionadas