Acabo de agregar xUnit a nuestro proyecto de prueba (para el Asserts, seguimos usando MSTest como marco) e inmediatamente las ejecuciones de prueba se negaron a ejecutar cualquiera de las pruebas. Este es el mensaje de error:La ejecución de MSTest falla porque no se confía en el ensamblaje de origen
No se pudo hacer cola prueba '{....}' Prueba tema despliegue de ejecución: El ubicación del archivo o directorio '... xUnit.dll' no es Confiado
Me costó un par de 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 this blog posting.
Básicamente, la corrección hace clic derecho en el archivo dll (xunit.dll por ejemplo) en Windows Explorer, vaya a Propiedades y hace 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 mencionan un par de comentaristas, es posible que también deba reiniciar Visual Studio para que esto surta efecto.
Por algún motivo extraño, no tengo la opción de "Desbloquear". No hay botón Y tengo lo último y mejor instalado en mi máquina XP. – irperez
¡Gracias! Después de hacer esto, tuve que reiniciar Visual Studio para que las pruebas se ejecutaran correctamente. – StriplingWarrior
Para dejarlo en claro, se llega al botón 'Desbloquear' accediendo a las propiedades del dll en Windows Explorer, NO en Visual Studio. Esto me confundió por un momento. –
En mi equipo tuvimos el mismo problema.
Su solución no funcionó, pero this post by Charles Sterling ayudó.
Se utilizó la línea siguiente:
caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare
Esto ya no es necesario después de instalar .Net 3.5 SP1, ya que esta versión cambia el nivel de confianza predeterminado de los recursos compartidos de red. Hasta que instale 3.5SP1, esta es probablemente la mejor solución. –
@Bert Huijben, eso es correcto (http://stackoverflow.com/questions/148879/why-does-my-net-application-crash-when-run-from-a-network-drive/). Pero seguimos teniendo el problema incluso después de 3.5SP1, pero solo cuando se ejecutaba a través de MSTest aparecía el error, simplemente ejecutaba la aplicación, sin problemas. –
Este me funcionó por completo también. ¡Buen espectaculo! –
Después de tener este problema y horas de encendido tratando de conseguir "Desbloquear" para pegar más de unos pocos minutos y/o averiguar caspol en vano, me finalmente encontró un pequeño tidbit a través de Google que los ensamblajes se bloquearán nuevamente la próxima vez que construya o reconstruya el proyecto, ya que se vuelven a copiar desde su ubicación de origen original. (Supongo que no me di cuenta de que esto ocurrió antes con los conjuntos de referencias, pero de todos modos ...)
Mi solución para este fue el siguiente:
Copiar todos los archivos DLL necesarios a otro lugar para segura manteniendo así
Retire los referencias en Visual Studio
eliminar físicamente los archivos DLL en la carpeta bin
desbloquear los archivos DLL individualmente en el lugar donde se fueron copiados fuera
agregar las referencias vuelta en Visual Studio desde el sosteniendo punto
cada generación subsiguiente o reconstruir trabajados bien luego.
Tuve el mismo problema con las DLL descargadas bloqueadas por Vista. Necesita derechos de administrador para obtener el botón "Desbloquear" en las Propiedades del archivo. I simplemente reemplazó las DLL con la última versión del control de código fuente (TFS) donde las había asignado anteriormente.
Corriendo en una máquina XP (incluso con .NET 3.5 SP1 instalado) No pude hacer funcionar ninguna de las otras soluciones aquí enumeradas.
Sin embargo trabaja de la misma post by Charles Sterling que las referencias Davy Landman, finalmente tuvieron éxito con esta variación:
Después de estos pasos, puedo ejecutar pruebas, incluso después de reinicios y reconstrucciones.
EDITAR: como se describe en this answer, 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.
Cuando más tarde me mudé a una caja Win7/64, este enfoque no funcionó. Sin embargo, la solución 'caspol' de Davy Landman anterior funcionó bien. – Eric
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.
También intenté abrir el archivo en el bloc de notas ++ y cambiarle el nombre. Un enfoque un tanto diferente, pero funcionó para mí. El sistema de archivos local luego piensa que proviene de la misma máquina.
¿Exactamente qué archivo está abriendo en el bloc de notas para cambiar el nombre? –
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 realmente esto funcionando.
Pruébalo.
:)
PD: También he eliminado todos los viejos de DLL en mi carpeta bin, sólo para asegurarse de Visual Studio no recogía el anterior.
No es solo el moq.dll que debe desbloquearse. 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í.
filePropertiesAllow
En VS2008 el construido en el marco de pruebas se limita a informar "No ejecutado". ¡Qué gran ayuda fue eso! –
Jeez, ¡quien en MS decidió que una ubicación debía ser "de confianza" solo para realizar una prueba frustrada, ¡necesitaba disparar! – Calanus