unit - La ejecución de MSTest falla porque el ensamblaje de origen no es de confianza

ping ms test

Question

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

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

Answer 1

Después de tener este problema y horas ardientes tratando de "Desbloquear" para permanecer por más de unos pocos minutos o averiguando caspol en vano, finalmente encontré un pequeño tidbit a través de Google que los ensamblajes se bloquearán nuevamente la próxima vez que construyas o reconstruir el proyecto, ya que se vuelven a copiar desde su ubicación de origen original. (Supongo que nunca me di cuenta de que esto sucedió antes con las asambleas de referencias, pero de todos modos ...)

Mi solución para esto fue la siguiente:

1. Copie todas las DLL necesarias en otro lugar para mantenerlas seguras

2. Eliminar las referencias en Visual Studio

3. Eliminar físicamente los archivos DLL en la carpeta bin

4. Desbloquee los archivos DLL individualmente en el lugar donde fueron copiados

5. Agregue las referencias en Visual Studio desde el punto de espera

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

Answer 2

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

Sin embargo, trabajando desde la misma publicación de Charles Sterling a la que hace referencia Davy Landman, finalmente tuve éxito con esta variación:

1. Ejecute la herramienta de configuración de .NET 2.0 (Configuración ... Panel de control ... Herramientas administrativas ... Configuración de .NET Framework 2.0)
2. Haga clic en "Mi PC ... Política de seguridad en tiempo de ejecución ... Máquina ... Grupos de códigos ... Código_Todo"
3. Cree un nuevo grupo de códigos con la condición de membresía 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 , es posible que deba instalar .NET SDK (que es diferente del .NET Framework) para tener la herramienta de configuración .NET 2.0 en su sistema.

Answer 3

En mi equipo tuvimos el mismo problema.

Su solución no funcionó, pero esta publicación de Charles Sterling ayudó.

Usamos la siguiente línea:

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

Answer 4

Me tomó varios intentos encontrar la respuesta en Google, así que la voy a poner aquí en caso de que alguien más se encuentre con el mismo problema. Una descripción detallada se puede encontrar en esta publicación del blog .

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

Como mencionaron algunos comentaristas, es posible que también deba reiniciar Visual Studio para que esto surta efecto.

Answer 5

No es solo el moq.dll el que necesita ser desbloqueado. El archivo zip más reciente incluye un archivo moq.xml y moq.pdb; al hacer referencia a la DLL, también copia estos otros dos archivos en las carpetas bin. Si los tres no se han desbloqueado, las pruebas no se ejecutarán, descubrí.

Answer 6

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

Solo después de des-chequear ese atributo, aplicando, luego seleccionando desbloquear hice que realmente funcionara.

Dale una oportunidad.

:)

PD: También borré todos los dll viejos en mi carpeta bin, solo para asegurarme de que Visual Studio no recogiera el anterior.

Answer 7

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 luego piensa que proviene de la misma máquina.

Answer 8

Tuve el mismo problema con los archivos DLL descargados bloqueados por Vista. Necesita derechos de administrador para obtener el botón "Desbloquear" en las Propiedades del archivo. Simplemente reemplacé las DLL con la última versión del control de fuente (TFS) donde las había confiado antes.

Answer 9

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

Tuve que desbloquear el archivo zip original que descargué. A continuación, copie la DLL del archivo zip nuevamente. Funciona después de eso.

Answer 10

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