visual unitarias unit test studio pruebas proyecto hacer ejecutar c# visual-studio-2010 vs-unit-testing-framework

c# - unitarias - ¿Qué podría estar causando una excepción System.TypeLoadException en una prueba de unidad de Visual Studio?



unit test c# visual studio 2013 (10)

Tengo una biblioteca de clases C # .NET MyClassLibrary que compila bien. Estoy intentando crear un proyecto de prueba unitaria para él (utilizando Visual Studio Unit Testing Framework, con Visual Studio 2010). La biblioteca de clases tiene grandes clases, pero cada vez que ejecuto la prueba más simple contra la clase más simple, obtengo la siguiente excepción:

Método de prueba MyClassLibraryTest.MyClassLibraryTests.MySimpleClassTest lanzó la excepción: System.TypeLoadException: No se pudo cargar el tipo ''MyClassLibrary.MySimpleClass'' del ensamblado ''MyClassLibrary, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null''.

Todos los proyectos con los que estoy tratando están en la misma solución, y todos están compilados para .NET 4.0. Todo esto está en una máquina de Windows 7 de 64 bits.

Aquí está la parte rara: cuando " Ejecuto " la prueba, obtengo el error anterior. Pero cuando " depuro " la prueba, funciona bien. ¿Por qué?


El conjunto MyClassLibrary se configuró en modo x86 en el administrador de configuración. Cambiando esto a x64 lo arreglé. Realmente deseo que Visual Studio detecte esto y lo reporte como un error menos oscuro.


El mismo mensaje aquí, pero tampoco pude depurar la prueba.

En mi caso, la DLL que estaba probando se implementó en el GAC (un requisito de BizTalk). Había creado una nueva clase y la estaba probando, pero no había GAC ​​el DLL nuevamente desde que se agregó la clase bajo prueba.


En caso de que esto ayude a otros con el mismo error (me doy cuenta de que no responde directamente a la pregunta re Release / Debug); Me fusioné en un proyecto heredado con un espacio de nombres que entró en conflicto con uno existente, por lo que le cambié el nombre. Recibí este error al intentar crear un formulario de ese proyecto.

Verifiqué que el objetivo de la plataforma era el mismo, y eliminé los directorios. / Bin / para garantizar una reconstrucción limpia, eliminé la referencia al proyecto fusionado y lo volví a agregar, pero sigue siendo el mismo error.

Finalmente (!) Marqué el Nombre del ensamblaje en las propiedades del proyecto (haga clic derecho en el proyecto, seleccione ''propiedades'', seleccione la pestaña ''Aplicación'') y lo modifiqué para que coincida con el espacio de nombres predeterminado, y todo está bien.


Me golpeé la cabeza contra ésta durante una hora. El problema era que tenía un proyecto de línea de comandos llamado Something.exe, que estaba usando un proyecto de biblioteca de clases llamado Something.dll.


Me pasó a mí también. En mi caso, el problema surgió porque el proyecto probado y el proyecto de pruebas unitarias tenían el mismo nombre. Si este también es su caso, cambie el nombre de uno de los proyectos y cambie el nombre del archivo de salida para corregirlo.


Me pasó a mí también. Está relacionado con la construcción para x64, versión y modo x86. En mi caso, eliminé las carpetas de mi contenedor (depuración / lanzamiento / x86 en ensamblajes de referencia y prueba de unidad) y volví a ejecutar la prueba de unidad. VS2010 reportó un poco el error en la ventana de salida. Eso me lo resolvió.


Me sucedió cuando intentaba agregar un proyecto de prueba con el mismo nombre de proyecto principal.

El nombre de mi proyecto principal era: Calculator.OperationsManager El nombre de mi proyecto de prueba era: Calculator.OperationsManager

He cambiado el nombre del proyecto de prueba como Calculator.OperationsManager.Test y todo salió bien.


Pasé por esto hoy y aunque dejaría mi arreglo.

Especificaciones: VS 2013 / .Net 4.0

Solución: vaya a Menú> Prueba> Configuración de prueba> Arquitectura del procesador predeterminada> X64


Tuve este error al usar NUnit 3 en VS 2013. Lo resolví eliminando la referencia de ensamblaje en mi proyecto de prueba para el ensamblaje que contenía el tipo que no se encontraba y luego volví a agregar la referencia.


Tuve un problema similar al de Trey, pero en lugar de BizTalk, tengo una solución de SharePoint que también usa la implementación de GAC. GAC tenía una asamblea más antigua. Cuando quité el ensamblaje de GAC retrayendo la solución, la prueba pasó.