I have a .NET library project with about 500 unit tests. All these tests run fine in Visual Studio 2012. However, some of my tests fail in Visual Studio 2010. In these failing tests, I use Moq to mock several Interop Types from Microsoft.Office.Interop.Excel
. The test fails immediately when attempting to access these mocked interop types:
Error: Missing method 'instance class Microsoft.Office.Interop.Excel.Range [ExcelAddIn.Core] Microsoft.Office.Interop.Excel.ListRow::get_Range()' from class 'Castle.Proxies.ListRowProxy'.
This exception implies that I forgot to setup the appropriate property getter on my mock. Which is not the case:
_listRowMock.Setup(m => m.Range).Returns(_rangeMock.Object);
Now I can imagine that Moq might not work too well with Interop Types. But what I find most puzzling is that these tests run fine in Visual Studio 2012, but fail in Visual Studio 2010.
Why is my Visual Studio influencing the behavior of my code?
UPDATE: 3-11-2012
Ok, so I got it down to this:
- I have two projects; Core and Core.UnitTest. Core is the actual library while Core.UnitTest is a unit test project of the Core library.
- Both projects reference Microsoft.Office.Interop.Excel with Embed Interop Types enabled.
- Because EIT is enabled, both projects include their own "view" of the Microsoft.Office.Interop.Excel library. The view includes all classes, methods and properties that are used in their respective project.
- Because both projects use different classes, methods and properties of the Microsoft.Office.Interop.Excel, the embedded types of both libraries differ. E.g. ListRow in Core has an Index and Range property, whereas ListRow in Core.UnitTest only has the Range property.
- Although both types are different and do not share a common interface or super class, they are equivalent. This means that the CLR will treat them as if they are the same and will allow you to use these types across assembly boundaries. E.g. an instance of ListRow from Core.UnitTest will work fine when passed to a method in the Core library. The shared Range property will function, whereas the missing Index property will throw a MissingMethodException on access.
- The aforementioned behavior even works with mocked types. An mocked object of Mock[Excel.ListRow] will work fine when crossing the assembly boundary.
- Unfortunately, the behavior described in the previous point only works when I build my assemblies in Visual Studio 2012. When I build my assemblies in Visual Studio 2010 and debug my code, I can see the mocked ListRow instance being passed into a method of my Core project. The moment the instance crosses the assembly boundary, all methods and properties of ListRow lose their implementation and throw MissingMethodExceptions.
- Now for the fun part, I actually managed to mitigate this issue by ensuring that both embedded types of ListRow are aligned. E.g. in order for the compiler to create the same view of ListRow in both projects, I made sure that I used the exact same methods and properties in my UnitTest project. This means adding dummy lines like: var dummy = listRow.Index. Once I had the compiler creating identical views of my embedded ListRow type, the instance was allowed to cross assembly boundaries without losing its implementation.
The question still remains though: What causes this difference in behavior between Visual Studio 2010 and Visual Studio 2012?
UPDATE: 9-11-2012
Demo Solution: http://temp-share.com/show/KdPf6066h
I have created a small solution to demonstrate the effect. The solution consists of a library and a UnitTest project. Both reference Microsoft.Office.Interop.Excel.Range with EIT enabled. The test works fine in VS2012 but throws MissingMethodException in VS2010. Uncommenting the dummy line in the test will make it work in VS2010.
FINAL UPDATE: 29-12-2012
My apologies for the late update. A colleague of mine found a solution, however I was unable to reproduce it on my machine. In the meantime our company has made the switch to TFS2012 so this is no longer a blocking issue for me. The two most important conclusions my colleague made were:
- The semantics of the "Any CPU" platform have changed from Visual Studio 2010 to Visual Studio 2012. This will result in different .DLL's being generated depending on whether you are using VS2010 or VS2012.
- Both projects referenced different versions of Microsoft.Office.Interop.Excel.
I checked my projects and straightened out the references, but it made no difference. After that, I tried different variations of platforms in both VS2010 and VS2012 but was unable to produce a satisfactory result. I will accept Jeremy's answer as it was the most helpful. Thank you all for your assistance.