No se pudo cargar el tipo de error de ensamblaje

He escrito la siguiente prueba simple para tratar de aprender la interfaz fluida de Castle Windsor:

using NUnit.Framework;
using Castle.Windsor;
using System.Collections;
using Castle.MicroKernel.Registration;

namespace WindsorSample {
    public class MyComponent : IMyComponent {
        public MyComponent(int start_at) {
            this.Value = start_at;
        }
        public int Value { get; private set; }
    } 
    public interface IMyComponent {
        int Value { get; }
    }

    [TestFixture]
    public class ConcreteImplFixture {
        [Test]
        public void ResolvingConcreteImplShouldInitialiseValue() {
            IWindsorContainer container = new WindsorContainer();
            container.Register(Component.For<IMyComponent>().ImplementedBy<MyComponent>().Parameters(Parameter.ForKey("start_at").Eq("1")));
            IMyComponent resolvedComp = container.Resolve<IMyComponent>();
            Assert.AreEqual(resolvedComp.Value, 1); 
        }
    }
}

Cuando ejecuto la prueba a través de TestDriven.NET obtengo el siguiente error:

System.TypeLoadException : Could not load type 'Castle.MicroKernel.Registration.IRegistration' from assembly 'Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.
at WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue()

Cuando ejecuto la prueba a través de la GUI de NUnit obtengo:

WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue:
System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Windsor, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The system cannot find the file specified.

Si abro la Asamblea que estoy haciendo referencia en Reflector, puedo ver que su información es:

Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc

y que definitivamente contiene Castle.MicroKernel.Registration.IRegistration

¿Qué podría estar pasando?

Debo mencionar que los binarios se tomaron de la última versión de Castle, aunque nunca he trabajado con nant, así que no me molesté en volver a compilar desde la fuente y simplemente tomé los archivos en el directorio bin. También debo señalar que mi proyecto se compila sin problemas.

¿Está el ensamblado en la caché de ensamblados global (GAC) o en algún lugar donde podría estar anulando el ensamblado que cree que se está cargando? Esto suele ser el resultado de la carga de un ensamblado incorrecto, para mí significa que generalmente tengo algo en el GAC que anula la versión que tengo en bin / Debug.

Si tiene un proyecto que hace referencia a otro proyecto (como un tipo de 'Aplicación de Windows' que hace referencia a una 'Biblioteca de clases') y ambos tienen el mismo nombre de ensamblado, obtendrá este error. Puede nombrar fuertemente el proyecto al que se hace referencia o (incluso mejor) cambiar el nombre del ensamblaje del proyecto que hace referencia (en la pestaña 'Aplicación' de las propiedades del proyecto en VS).

La solución a esto para mí no se mencionó anteriormente, así que pensé en agregar mi respuesta a la cola larga ...

Terminé teniendo una referencia anterior a una clase (an HttpHandler) en web.config que ya no se usaba (y ya no era una referencia válida). Por alguna razón, se ignoró mientras se ejecutaba en Studio (¿o tal vez todavía tengo esa clase accesible dentro de mi configuración de desarrollo?) Y, por lo tanto, solo recibí este error una vez que intenté implementar en IIS. Busqué el nombre del ensamblado en web.config, eliminé la referencia del controlador no utilizado, luego este error desapareció y todo funciona muy bien. Espero que esto ayude a alguien más.

Tuve el mismo problema y, para mí, no tuvo nada que ver con el espacio de nombres o el nombre del proyecto.

Pero como varios usuarios insinuaron, tenía que ver con un ensamblaje antiguo que aún se hace referencia.

Recomiendo eliminar todas las carpetas "bin" / binarias de todos los proyectos y reconstruir la solución completa. Esto eliminó cualquier ensamblado potencialmente desactualizado y luego MEF exportó todos mis complementos sin problemas.

Recibí este error y nada de lo que encontré en StackOverflow o en otro lugar lo resolvió, pero la respuesta de bmoeskau a esta pregunta me indicó la dirección correcta para la solución, que aún no se ha mencionado como respuesta. Mi respuesta no está estrictamente relacionada con la pregunta original, pero la estoy publicando aquí bajo el supuesto de que alguien que tenga este problema encontrará el camino aquí buscando en Google o algo similar (como yo dentro de un mes cuando esto me vuelva a morder , arg!).

Mi ensamblado está en el GAC, por lo que teóricamente solo hay una versión del ensamblado disponible. Excepto que IIS está almacenando en caché la versión anterior y me está dando este error. Acababa de cambiar, reconstruir y reinstalar el ensamblaje en el GAC. Una posible solución es usar el Administrador de tareas para eliminar w3wp.exe . Esto obliga a IIS a volver a leer el ensamblado del GAC: problema resuelto.

Versión = 1.0.3.0 indica Castle RC3, sin embargo, la interfaz fluida se desarrolló algunos meses después del lanzamiento de RC3. Por lo tanto, parece que tiene un problema de versiones. Tal vez tienes Castle RC3 registrado en el GAC y está usando ese ...

Recibo esto ocasionalmente y siempre ha estado dispuesto a tener la asamblea en el GAC

Si este error se debe al cambio del espacio de nombres, asegúrese de que la carpeta de ese proyecto cambia de nombre al mismo nombre y cierre VS.NET Edite el proyecto que tiene el problema con el Bloc de notas y reemplace los nodos

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> "AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace" AssemblyName>

Eliminar mi archivo .pdb para el dll resolvió este problema para mí. Supongo que tiene algo que ver con el hecho de que la dll se creó con ILMerge.

Cuando me encuentro con tal problema, encuentro la herramienta FUSLOGVW muy útil. Está comprobando la información de enlace del ensamblaje y la registra por usted. A veces faltan las bibliotecas, a veces GAC tiene diferentes versiones que se están cargando. A veces, la plataforma de bibliotecas referenciadas está causando los problemas. Esta herramienta deja en claro cómo se resuelven los enlaces de las dependencias y esto realmente puede ayudarlo a investigar / depurar su problema.

Visor de registro de Fusion / fuslogvw / Visor de registro de enlace de ensamblajes. Consulte más / descargue aquí: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx .

Tuve este problema después de factorizar un nombre de clase:
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

Detener IIS y eliminar el contenido Temporary ASP.NET Filesme lo arregló.

Dependiendo de su proyecto (32/64 bits, versión .net, etc.), las Temporary ASP.NET Filesdiferencias correctas :

• 64 bits
  %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
• 32 bits
  %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
• En mi máquina de desarrollo estaba (¿Porque quizás sea IIS Express?)
  %temp%\Temporary ASP.NET Files

Tal vez no sea tan probable, pero para mí fue causado por mi aplicación que intentaba cargar una biblioteca con el mismo nombre de ensamblado (xxx.exe cargando xxx.dll).

Solo encuentra esto con otra causa:

ejecutando pruebas unitarias en modo de lanzamiento, pero la biblioteca que se estaba cargando era la versión del modo de depuración que no se había actualizado

Otra solución más: archivos DLL antiguos apuntando entre sí y almacenados en caché por Visual Studio en

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

Salga de VS, elimine todo en esta carpeta y Bob es su tío.

Tuve el mismo problema. Acabo de resolver esto actualizando el ensamblado a través de GAC.

Para utilizar gacutil en una máquina de desarrollo vaya a: Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010).

Usé estos comandos para desinstalar y reinstalar respectivamente.

gacutil /u myDLL

gacutil /i "C:\Program Files\Custom\mydllname.dll"

Nota: no he desinstalado mi dll en mi caso, acabo de actualizar dll con la ruta actual.

Me encontré con este escenario al intentar cargar un tipo (a través de la reflexión) en un ensamblado que se construyó con una versión diferente de una referencia común a la aplicación donde apareció este error.

Como estoy seguro de que el tipo no ha cambiado en ambas versiones del ensamblado, terminé creando un solucionador de ensamblado personalizado que asigna el ensamblaje que falta al que mi aplicación ya ha cargado. La forma más sencilla es agregar un constructor estático a la clase del programa así:

using System.Reflection
static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "<AssemblyName>")
        {
            // Load assembly from startup path
            return Assembly.LoadFile($"{Application.StartupPath}\\<AssemblyName>.dll");
        }
        else
        {
            return null;
        }
    };
}

Por supuesto, esto supone que el ensamblaje se encuentra en la ruta de inicio de la aplicación y se puede adaptar fácilmente.

Solo encuentra esto con otra causa:

Estaba usando un ensamblado combinado creado con ILRepack. El ensamblado desde el que está consultando los tipos debe ser el primero en pasar a ILRepack o sus tipos no estarán disponibles.

Es posible que pueda resolver esto con redireccionamientos vinculantes en * .config. http://blogs.msdn.com/b/dougste/archive/2006/09/05/741329.aspx tiene una buena discusión sobre el uso de componentes .net más antiguos en marcos más nuevos. http://msdn.microsoft.com/en-us/library/eftw1fys(vs.71).aspx

Esto suele suceder cuando tiene una versión de su ensamblado implementada en el GAC pero no se ha actualizado con nuevas clases que podría haber agregado en el ensamblado en su IDE. Por lo tanto, asegúrese de que el ensamblado del GAC esté actualizado con los cambios que podría haber realizado en su proyecto.

Por ejemplo, si tiene una biblioteca de clases de Common y en esa biblioteca de clases tiene el tipo Common.ClassA y la implementa en el GAC con nombre seguro. Viene más tarde y agrega otro tipo llamado Common.ClassB y ejecuta su código en su IDE sin implementar primero los cambios que realizó en el GAC de Common con el tipo Common.ClassB recién agregado.

Obtuve el mismo error después de actualizar un dll referenciado en un proyecto ejecutable de escritorio. El problema fue que las personas aquí mencionadas relataron una referencia antigua y fácil de solucionar, pero no se ha mencionado aquí, por lo que pensé que podría ahorrar tiempo a otras personas.

De todos modos, actualicé dll A y obtuve el error de otro dll referenciado, llamémoslo B aquí, donde dll A tiene una referencia a dll B.

La actualización de dll B solucionó el problema.

Agregar su DLL a GAC ​​(caché de ensamblados global)

Símbolo del sistema de Visual Studio => Ejecutar como administrador

gacutil / i "ruta del archivo dll"

Puede ver el ensamblaje agregado C: \ Windows \ system32 \

También resolverá la falta de dll o "No se pudo cargar el archivo o ensamblado" en la tarea SSIS Script

Experimenté un problema similar en Visual Studio 2017 usando MSTest como marco de prueba. Estaba recibiendo excepciones System.TypeLoadException cuando ejecutaba algunas (no todas) pruebas unitarias, pero esas pruebas unitarias pasarían cuando se depuraran. Finalmente hice lo siguiente que resolvió el problema:

1. Abra el archivo Local.testsettings en la solución
2. Ve a la configuración de "Prueba unitaria"
3. Desmarque la opción "Usar el contexto de carga para ensamblados en el directorio de prueba". caja

Después de seguir estos pasos, todas las pruebas unitarias comenzaron a pasar cuando se ejecutaron.

Experimenté lo mismo que el anterior después de eliminar la firma de ensamblajes en la solución. Los proyectos no se construirían.

Descubrí que uno de los proyectos hacía referencia al paquete StrongNamer NuGet, que modifica el proceso de compilación e intenta firmar paquetes Nuget no firmados.

Después de eliminar el paquete StrongNamer, pude compilar el proyecto nuevamente sin firmar / nombrar los ensamblados.

Si se trata de una aplicación de Windows, intente buscar un duplicado en la caché de ensamblados global (GAC). Algo está anulando su versión bin / debug.

Si se trata de una aplicación web, es posible que deba eliminarla en el servidor y volver a cargarla. Si está publicando, es posible que desee marcar la casilla de verificación Eliminar todos los archivos existentes antes de la publicación. Dependiendo de la versión de Visual Studio, debería estar ubicado en Publicar> Configuración> Opciones de publicación de archivos

Acabo de resolver esto ejecutando el comando iisreset usando el símbolo del sistema ... Siempre lo primero que hago cuando recibo tales errores.