Eu tenho um projeto de biblioteca .NET com cerca de 500 testes de unidade. Todos esses testes funcionam bem no Visual Studio 2012. No entanto, alguns dos meus testes falham no Visual Studio 2010. Nesses testes com falha, eu usoMoq para zombar de vários tipos de interoperabilidade deMicrosoft.Office.Interop.Excel. O teste falha imediatamente ao tentar acessar esses tipos de interoperabilidade:

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 exceção implica que eu esqueci de configurar o getter de propriedade apropriado no meu mock. O que não é o caso:

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

Agora posso imaginar que o Moq pode não funcionar muito bem com os tipos de interoperabilidade. Mas o que eu acho mais intrigante é que esses testes funcionam bem no Visual Studio 2012, mas falham no Visual Studio 2010.

Por que meu Visual Studio está influenciando o comportamento do meu código?

ATUALIZAÇÃO: 3-11-2012

Ok, então eu entendi isso:

Eu tenho dois projetos; Core e Core.UnitTest. Core é a biblioteca real, enquanto Core.UnitTest é um projeto de teste de unidade da biblioteca Core.Ambos os projetos fazem referência ao Microsoft.Office.Interop.Excel com Embed Interop Types enabled.Como o EIT está habilitado, ambos os projetos incluem sua própria "exibição" da biblioteca Microsoft.Office.Interop.Excel. A visão inclui todas as classes, métodos e propriedades que são usados ​​em seus respectivos projetos.Como os dois projetos usam classes, métodos e propriedades diferentes do Microsoft.Office.Interop.Excel, os tipos incorporados de ambas as bibliotecas são diferentes. Por exemplo. ListRow no Core tem uma propriedade Index e Range, enquanto ListRow no Core.UnitTest tem apenas a propriedade Range.Embora os dois tipos sejam diferentes e não compartilhem uma interface comum ou superclasse, eles sãoequivalente. Isso significa que o CLR os tratará como se fossem os mesmos e permitirá que você use esses tipos nos limites da montagem. Por exemplo. uma instância do ListRow do Core.UnitTest funcionará bem quando passada para um método na biblioteca Core. A propriedade de intervalo compartilhada funcionará, enquanto a propriedade de índice ausente lançará uma MissingMethodException no acesso.O comportamento acima mencionado funciona mesmo com tipos ridicularizados. Um objeto ridicularizado do Mock [Excel.ListRow] funcionará bem ao cruzar o limite do conjunto.Infelizmente, o comportamento descrito no ponto anterior só funciona quando eu construo meus assemblies no Visual Studio2012. Quando eu construo minhas montagens no Visual Studio2010 e depurar meu código, posso ver a ocorrência escandalada de ListRow sendo passada para um método do meu projeto Core. No momento em que a instância cruza o limite de montagem, todos os métodos e propriedades do ListRow perdem sua implementação e lançam MissingMethodExceptions.Agora, para a parte divertida, eu realmente consegui atenuar esse problema, garantindo que ambos os tipos incorporados de ListRow estejam alinhados. Por exemplo. Para que o compilador crie a mesma exibição de ListRow em ambos os projetos, certifiquei-me de usar exatamente os mesmos métodos e propriedades em meu projeto UnitTest. Isso significa adicionar linhas simuladas como: var dummy = listRow.Index. Depois que o compilador criou visualizações idênticas do tipo ListRow incorporado, a instância teve permissão para cruzar os limites de montagem sem perder sua implementação.

A questão ainda permanece: O que causa essa diferença de comportamento entre o Visual Studio 2010 e o Visual Studio 2012?

ATUALIZAÇÃO: 9-11-2012

Solução de Demonstração: http://temp-share.com/show/KdPf6066h

Eu criei uma pequena solução para demonstrar o efeito. A solução consiste em uma biblioteca e um projeto UnitTest. Ambos referência Microsoft.Office.Interop.Excel.Range com EIT habilitado. O teste funciona bem no VS2012, mas lança MissingMethodException no VS2010. Uncommenting a linha fictícia no teste irá fazê-lo funcionar no VS2010.

ATUALIZAÇÃO FINAL: 29-12-2012

Minhas desculpas pela atualização tardia. Um colega meu encontrou uma solução, mas não consegui reproduzi-la na minha máquina. Enquanto isso, nossa empresa fez a mudança para o TFS2012, então isso não é mais um problema de bloqueio para mim. As duas conclusões mais importantes que o meu colega fez foram:

A semântica da plataforma "Any CPU" foi alterada do Visual Studio 2010 para o Visual Studio 2012. Isso resultará em diferentes .DLLs sendo gerados, dependendo se você estiver usando o VS2010 ou o VS2012.Ambos os projetos referenciaram diferentes versões do Microsoft.Office.Interop.Excel.

Eu chequei meus projetos e endireitei as referências, mas isso não fez diferença. Depois disso, tentei diferentes variações de plataformas no VS2010 e no VS2012, mas não consegui produzir um resultado satisfatório. Aceitarei a resposta de Jeremy, pois foi a mais útil. Obrigado a todos pela sua ajuda.