visual studio 2012 - visual - prevenir vstest discovery engine bloqueando DLL

visual studio code setup git

Question

Tengo algunas pruebas unitarias de C # para un proyecto VS2012 que llama a una DLL VS2010 c ++ utilizando DllImport Pinvoke.

Como evento de creación previa para el proyecto de prueba, copio la última versión de la DLL al proyecto binario para la prueba.

Esto falla repetidamente si vstest.discoveryengine se está ejecutando. Parece que el ''motor de descubrimiento'' está cargando las pruebas y manteniendo el bloqueo en la DLL.

Si mato vstest discovery engine, entonces puedo construir y ejecutar las pruebas. de lo contrario, la compilación falla y VS2012 ofrece ejecutar una versión anterior (con un cuadro de diálogo modelo que no tiene la opción "no volver a mostrar este mensaje")

¿Hay algo que pueda hacer para forzar que el proyecto de prueba descargue la DLL cuando no esté ejecutando las pruebas o deshabilitar el archivo ejecutable de detección en segundo plano?

He pirateado una solución al crear un ejecutable llamado Kealakekua que mata a vstest.discoveryengine.x86, vstest.executionengine.x86, y con eso como la primera parte del evento previo a la compilación, puede copiar los archivos y compilar, pero preferiría No estar peleando en el estudio visual por mi archivo.

Answer 1

Recientemente también tuve este problema y el problema fue causado por mi propio código de usuario.

Durante el descubrimiento de pruebas, todas las clases de prueba se crean instancias y en uno de nuestros constructores de clases de prueba, se iniciaron clases de negocios bastante complejas. El problema es que durante la inicialización de la misma se creó un subproceso en segundo plano, que hizo lo siguiente:

socket.Read(...)

Este hilo siguió funcionando para siempre esperando que llegaran algunos datos de socket y, como resultado, bloquearon nuestro ensamblaje.

Entonces, la solución para mí fue asegurarse de que este código no se llame durante el descubrimiento de prueba.

Puede verificar, si está afectado por este problema, adjuntando Visual Studio al motor de descubrimiento de prueba cuando haya bloqueado algún ensamblaje. Después de presionar pausa, normalmente verá que la línea de ejecución actual se encuentra en algún lugar de su propio código de usuario (también verifique la ventana Subprocesos).

Answer 2

Tuve un problema similar en el que creé un proyecto de "Prueba" que en realidad no tenía ninguna prueba. (Como desarrollador de la Biblioteca de C ++, quería asegurarme de que ciertos encabezados pudieran compilarse con CLR habilitado, por lo que hice un proyecto CLR falso para compilarlos con CLR. Si se compilaba, se pasaba.) La DLL creada estaba siendo Mantenido abierto indefinidamente por el vstest.discoveryengine.

Lo arreglé agregando una prueba Ignorada al proyecto. Creo que vstest.discoveryengine retendrá la dll hasta que encuentre todas las pruebas en la dll, pero si no se encuentran pruebas, entonces la retendrá para siempre.

La prueba que agregué (creo que es la prueba predeterminada). Observe el TEST_IGNORE () para asegurarse de que no se ejecute:

#include <CppUnitTest.h>
namespace CLRTests
{
TEST_CLASS(CLRTestsClass)
{
public:
BEGIN_TEST_METHOD_ATTRIBUTE(CLRTest1)
TEST_OWNER(L"")
TEST_DESCRIPTION(L"")
TEST_PRIORITY(1)
TEST_IGNORE()
END_TEST_METHOD_ATTRIBUTE()
TEST_METHOD(CLRTest1)
{
// TODO: Your test code here
}
};
}

Espero que esto sea posible en su situación.