2010-04-13 14 views
11

Tengo diferentes proyectos escritos en .NET 3.5 y algunos proyectos de pruebas unitarias para cubrirlos. Al convertir mi solución para ser utilizada en Visual Studio 2010, mantengo todos mis proyectos en 3.5 pero las pruebas unitarias están forzadas a 4.0? De esta forma ya no puedo usarlos con mis proyectos regulares.¿Visual Studio 2010 solo ejecutará 4.0 unidades de prueba?

Resultando en esto: No se pudo cargar el archivo o ensamblado 'xxx.xxx.Core.UnitTest' o una de sus dependencias. Este ensamblado está creado por un tiempo de ejecución más nuevo que el tiempo de ejecución cargado actualmente y no se puede cargar.

¿No puedo probar la unidad de ningún proyecto a menos de 4.0? ¿O estoy haciendo algo mal aquí?

Respuesta

8

Actualmente la triste respuesta es sí, solo se admiten las pruebas creadas con VS2010 (.NET 4.0).

Al parecer esta hecha a propósito: échale un vistazo a esta "bug" report at Microsoft connect para obtener más detalles.

actualización
después de Microsoft ha visto el error de su camino que han añadido .NET 3.5 pruebas de unidad de apoyo en el SP1 de VS2010 - todos los detalles pueden ser encontrados in this post.

También puede volver a destino existente .NET 4.0 pruebas unitarias - How to re-target unit-tests to .Net Framework 3.5 in VS 2010 SP1

+1

Eso es sombrío si es verdad. Pero como esto en lo que respecta a MSTest, entonces no es un gran problema después de todo. – Finglas

+0

@Finglas Desafortunadamente esto rompe el soporte de Gallio (MbUnit) para mostrar las pruebas del proyecto, ya que las ventanas solo se muestran para los proyectos de prueba [MS]. –

3

Si bien los proyectos de prueba se convierten a Visual Studio 2010 Proyecto de prueba y compilaron específica para la plataforma .NET 4.0 por suerte todos los ensamblados que referencia y la prueba en sus pruebas aún puede ser .NET 3.5 (o lo que sea) ensambles. Cualquier otra cosa sería desastroso. Pero sí, ya no puede usar Visual Studio 2008 para ejecutar esos proyectos de prueba.

Una solución, por supuesto, sería mantener el código fuente de las pruebas, pero tener dos proyectos de prueba diferentes, uno para VS2008 y otro para VS2010 usando el mismo código fuente de prueba. engorroso, pero una solución de trabajo.