La ejecución de MSTest falla porque el ensamblado de origen no es confiable

StackOverflow https://stackoverflow.com/questions/201327

  •  03-07-2019
  •  | 
  •  

Pregunta

Acabo de agregar xUnit a nuestro proyecto de prueba (para los Asserts, todavía estamos usando MSTest como marco) e inmediatamente las ejecuciones de prueba se negaron a ejecutar cualquiera de las pruebas. Este es el mensaje de error:

  

Error al poner en cola la ejecución de la prueba '{....}'   Problema de implementación de ejecución de prueba: el   ubicación del archivo o directorio   '... xUnit.dll' no es de confianza.

¿Fue útil?

Solución

Me tomó varios intentos para encontrar la respuesta en Google, así que la pongo aquí en caso de que alguien más encuentre el mismo problema. Puede encontrar una descripción detallada en publicación de este blog .

Básicamente, la solución hace clic derecho en el archivo dll (xunit.dll por ejemplo) en el Explorador de Windows, va a Propiedades y hace clic en " Desbloquear " en la parte inferior de la pestaña junto al texto 'Seguridad'. Parece que Vista / Windows 2008 marcará automáticamente los ensamblajes que provienen de otras máquinas o de Internet como inseguros.

Como han mencionado algunos comentaristas, es posible que también deba reiniciar Visual Studio para que esto tenga efecto.

Otros consejos

En mi equipo tuvimos el mismo problema.

Su solución no funcionó, pero este post de Charles Sterling hizo ayuda.

Utilizamos la siguiente línea: 

caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare

Después de tener este problema y las horas de grabación, intenta obtener " Desbloquear " para quedarme más tiempo que unos pocos minutos y / o descifrar caspol sin éxito, finalmente encontré un pequeño detalle a través de Google de que los ensamblajes se bloquearán de nuevo la próxima vez que construyas o reconstruyas el proyecto, ya que se vuelven a copiar de su ubicación de origen original. (Supongo que nunca noté que esto sucedió antes con los ensamblados de referencias, pero de todos modos ...)

Mi solución para esto fue la siguiente:

  1. Copie todas las DLL necesarias a otra lugar para la custodia

  2. Eliminar el referencias en Visual Studio

  3. Borre físicamente las DLL en el carpeta bin

  4. Desbloquear las DLL individualmente en el lugar donde fueron copiados

  5. Añade las referencias de vuelta en Visual Studio desde el lugar de retención

Cada posterior compilación o reconstrucción funcionó bien después.

Funcionando en una máquina XP (incluso con .NET 3.5 SP1 instalado) no pude obtener ninguna de las otras soluciones enumeradas aquí para que funcionen.

Sin embargo, trabajando desde el mismo post por Charles Sterling que Davy Landman hace referencia , Finalmente tuve éxito con esta variación:

  1. Ejecute la herramienta de configuración .NET 2.0 (Configuración ... Panel de control ... Herramientas administrativas ... Configuración de .NET Framework 2.0)
  2. Haga clic hacia abajo para " Mi computadora ... Política de seguridad en tiempo de ejecución ... Máquina ... Grupos de códigos ... All_Code "
  3. Cree un nuevo grupo de códigos con la condición de miembro de " Zona " = " Intranet local " y asigne el conjunto de permisos " FullTrust "
  4. Reiniciar Visual Studio

Después de estos pasos, puedo ejecutar pruebas, incluso después de reinicios y reconstrucciones.

EDITAR: como se describe en esta respuesta , usted Es posible que deba instalar .NET SDK (que es diferente de .NET framework) para tener la herramienta de configuración .NET 2.0 en su sistema.

Tuve el mismo problema con moq. Pero no 'desbloquear'. Cada vez que lo desbloqueaba, todavía estaba bloqueado!?!?

Tuve que desbloquear el archivo zip original que descargué. A continuación, vuelva a copiar la DLL desde el archivo zip. Funciona después de eso.

Puede parecer muy obvio ahora, pero cuando estaba haciendo clic en desbloquear, el archivo se configuró como de solo lectura.

Solo después de deseleccionar ese atributo, aplicar, luego seleccionar Desbloquear, funcioné.

Dale una oportunidad.

:)

PS: También eliminé todos los archivos DLL antiguos de mi carpeta bin, solo para asegurarme de que Visual Studio no estaba detectando el archivo antiguo.

Tuve el mismo problema con las DLL descargadas bloqueadas por Vista. Necesita derechos de administrador para obtener el " Desbloquear " botón en las propiedades del archivo. Simplemente reemplacé las DLL con la última versión del control de fuente (TFS) donde las había confirmado anteriormente.

  • Vaya a file
  • Haga clic derecho y seleccione Properties
  • En el primer registro, haga clic en Allow

También intenté abrir el archivo en notepad ++ y cambiarle el nombre. Un enfoque ligeramente diferente, pero funcionó para mí. El sistema de archivos local cree que proviene de la misma máquina.

No es solo el moq.dll lo que necesita ser desbloqueado. El último archivo zip incluye un archivo moq.xml y moq.pdb; al hacer referencia a la dll, también se copian estos otros dos archivos en las carpetas bin. Si los tres no han sido desbloqueados, las pruebas no se ejecutarán, lo encontré.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top