Tengo un proyecto de biblioteca .NET con aproximadamente 500 pruebas de unidad. Todas estas pruebas se ejecutan bien en Visual Studio 2012. Sin embargo, algunas de mis pruebas fallan en Visual Studio 2010. En estas pruebas fallidas, usoMoq para burlarse de varios tipos de interoperabilidad deMicrosoft.Office.Interop.Excel. La prueba falla inmediatamente cuando se intenta acceder a estos tipos de interoperabilidad simulados:

Error: Missing method 'instance class Microsoft.Office.Interop.Excel.Range [ExcelAddIn.Core] Microsoft.Office.Interop.Excel.ListRow::get_Range()' from class 'Castle.Proxies.ListRowProxy'.

Esta excepción implica que olvidé configurar la propiedad apropiada en mi simulacro. Que no es el caso:

_listRowMock.Setup(m => m.Range).Returns(_rangeMock.Object);

Ahora puedo imaginar que Moq podría no funcionar muy bien con los tipos de interoperabilidad. Pero lo que me parece más desconcertante es que estas pruebas se ejecutan bien en Visual Studio 2012, pero fallan en Visual Studio 2010.

¿Por qué mi Visual Studio influye en el comportamiento de mi código?

ACTUALIZACIÓN: 3-11-2012

Ok, así que me puse a esto:

Tengo dos proyectos; Core y Core.UnitTest. Core es la biblioteca real, mientras que Core.UnitTest es un proyecto de prueba de unidad de la biblioteca Core.Ambos proyectos hacen referencia a Microsoft.Office.Interop.Excel con Incrustar tipos de interoperabilidad habilitados.Debido a que EIT está habilitado, ambos proyectos incluyen su propia "vista" de la biblioteca Microsoft.Office.Interop.Excel. La vista incluye todas las clases, métodos y propiedades que se utilizan en sus respectivos proyectos.Debido a que ambos proyectos utilizan diferentes clases, métodos y propiedades de Microsoft.Office.Interop.Excel, los tipos incrustados de ambas bibliotecas son diferentes. P.ej. ListRow en Core tiene una propiedad de índice y rango, mientras que ListRow en Core.UnitTest solo tiene la propiedad de rango.Aunque ambos tipos son diferentes y no comparten una interfaz común o una súper clase, sonequivalente. Esto significa que el CLR los tratará como si fueran los mismos y le permitirá utilizar estos tipos a través de los límites de ensamblaje. P.ej. una instancia de ListRow de Core.UnitTest funcionará bien cuando se pasa a un método en la biblioteca Core. La propiedad Range compartida funcionará, mientras que la propiedad Index faltada lanzará una MissingMethodException en el acceso.El comportamiento mencionado incluso funciona con tipos burlados. Un objeto simulado de Mock [Excel.ListRow] funcionará bien al cruzar el límite del ensamblaje.Desafortunadamente, el comportamiento descrito en el punto anterior solo funciona cuando compilo mis ensamblajes en Visual Studio2012. Cuando construyo mis ensamblajes en Visual Studio2010 y depurando mi código, puedo ver que la instancia de ListRow simulada se pasa a un método de mi proyecto Core. En el momento en que la instancia cruza el límite del ensamblaje, todos los métodos y propiedades de ListRow pierden su implementación y lanzan las MissingMethodExceptions.Ahora, para la parte divertida, logré mitigar este problema asegurándome de que ambos tipos integrados de ListRow estén alineados. P.ej. Para que el compilador pueda crear la misma vista de ListRow en ambos proyectos, me aseguré de usar exactamente los mismos métodos y propiedades en mi proyecto UnitTest. Esto significa agregar líneas ficticias como: var dummy = listRow.Index. Una vez que el compilador creó vistas idénticas de mi tipo ListRow incrustado, se permitió que la instancia cruzara los límites del conjunto sin perder su implementación.

Sin embargo, la pregunta sigue siendo: ¿Qué causa esta diferencia de comportamiento entre Visual Studio 2010 y Visual Studio 2012?

ACTUALIZACIÓN: 9-11-2012

Solución demo: http://temp-share.com/show/KdPf6066h

He creado una pequeña solución para demostrar el efecto. La solución consiste en una biblioteca y un proyecto UnitTest. Ambos hacen referencia a Microsoft.Office.Interop.Excel.Range con EIT habilitado. La prueba funciona bien en VS2012 pero lanza la excepción MissingMethodException en VS2010. Si no se comenta la línea de relleno en la prueba, funcionará en VS2010.

ACTUALIZACIÓN FINAL: 29-12-2012

Mis disculpas por la actualización tardía. Un colega mío encontró una solución, pero no pude reproducirla en mi máquina. Mientras tanto, nuestra compañía ha hecho el cambio a TFS2012, por lo que ya no es un problema de bloqueo para mí. Las dos conclusiones más importantes que mi colega hizo fueron:

La semántica de la plataforma "Cualquier CPU" ha cambiado de Visual Studio 2010 a Visual Studio 2012. Esto resultará en la generación de diferentes .DLL dependiendo de si está utilizando VS2010 o VS2012.Ambos proyectos hacían referencia a diferentes versiones de Microsoft.Office.Interop.Excel.

Revisé mis proyectos y enderezé las referencias, pero no hizo ninguna diferencia. Después de eso, probé diferentes variaciones de plataformas tanto en VS2010 como en VS2012, pero no pude producir un resultado satisfactorio. Aceptaré la respuesta de Jeremy ya que fue la más útil. Gracias a todos por su asistencia.