11

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.

Martin Devillers
  • 17,293
  • 5
  • 46
  • 88
  • 3
    Different versions of `Microsoft.Office.Interop.Excel`? – Claus Jørgensen Nov 02 '12 at 19:55
  • Wouldn't that cause compile time errors? – Martin Devillers Nov 02 '12 at 19:58
  • 2
    Not necessarily, if the signatures are the same. Your UT project might have a mismatch compared to the regular project. Open your MSTest files and verify. – Claus Jørgensen Nov 02 '12 at 20:02
  • Interestingly, both projects did reference different versions of the Excel. However, the problem remains after fixing the references. I took a look inside my assemblies using a disassembler but don't notice any significant differences. I have found that building in VS2010 and then testing in VS2012 will produce the same error. So it seems VS2010 builds a non-working UT, whereas VS2012 builds a working UT. Any ideas on how to debug this? – Martin Devillers Nov 02 '12 at 20:40
  • Are you running the tests inside Visual Studio? VS2012 uses a different test runner than VS2010. So if you have a updated R# version, or CI configuration, you probably aren't running the tests correctly. – Claus Jørgensen Nov 02 '12 at 21:10
  • Yes, I am running the tests inside Visual Studio. I've noticed the following behavior while debugging my tests. Inside my test, when I look at the mocked `ListRow`, I see it has a single `Range` property with a working getter. The mocked object is passed into a method I want to test. When I step into this method (which is in another assembly), my mocked object suddenly has more properties. In VS2012, the `Range` property still works though. In VS2010, it does not. All "extra" properties throw MissingMethodExceptions as you would expect. – Martin Devillers Nov 02 '12 at 21:19
  • @JeremyThompson That's odd, I just tested bounty creation on one of your attributed bounties and it worked. Do you see the 'start a bounty' button? Is it because you earned the original bounty? Anyhow, thanks for getting back on me. I will also ask one of the C# guru's at our office in the coming week. – Martin Devillers Nov 12 '12 at 10:58
  • I hope this isn't rude @EricLippert asking you to take a look. Sample 10 line repro in my answer. – Jeremy Thompson Nov 24 '12 at 04:38
  • 1
    Thank you very much for renewing the bounty. I haven't had time to contact our local brainiac but I will in the coming week. – Martin Devillers Nov 25 '12 at 11:29
  • Ok great. I have 14 hours left to award the bounty:) – Jeremy Thompson Nov 26 '12 at 05:47

4 Answers4

6

Edit : It works for me when I try it in Visual Studio 2012 and target .Net 4.0, only using the .Net PIA's not the COM ref. Same solution doesn't work in VS2010.

VS2010 loads version's 10.0.30319.1 of the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll's and VS2012 loads version's 11.0.50727.1. You can see the different version's in the Modules window.

I managed to get it working in VS2010:

enter image description here

Here is my solution http://temp-share.com/show/Pf3Ypip62 for everyone's convenience. It has all the Moq references included. I have Excel 2007 (ie v12) - so please adjust references to Office 14.

The Project with methods to be Tested has to use the PIA Microsoft.Office.Interop.Excel via the .Net reference tab.

In the Unit Test Project you have to use the Microsoft Excel 1X.0 Object Library via the COM reference tab - its an ActiveX.

The confusing thing is in Solution Explorer they are both called: Microsoft.Office.Interop.Excel

There is one other caveat that I dont know how to workaround - you have to use the .Net 3.5 framework and I was actually hoping Microsoft fixed it in 2012 as you found because I cant work how to do it with ALL projects in .Net 4.0. Some solutions with mixed projects targeting .Net 3.5 & 4.0 are ok.

I've had a lot of trouble with this, see here How do I avoid using dynamic when mocking an Excel.worksheet? and also see this question I asked: Mocked object doesn't have all properties shown in Intellisense - in one project but has them in the other.

Anyway this is how to get it working in VS 2010. I'm glad its resolved in 2012!

Community
  • 1
  • 1
Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
  • Thank you very much Jemery Thompson for your answer. However, what causes the test to work in VS2012 and fail in VS2010? Is it the different version of the `UnitTestFramework`? If so, how come I can get it to work in VS2012 by first compiling in VS2010 and then executing the test in VS2012? Wouldn't this imply that this is a compile-time issue and not a run-time issue? – Martin Devillers Nov 12 '12 at 07:59
  • 1
    Dll's are dynamically loaded. The issue is that each version of VS loads a different version of the .dll. It does not matter which version you use to compile, it only matters which version of the .dll is loaded at runtime. When you execute in VS2012 the correct .dll version is loaded to prevent the issue from appearing. If there was a way to force VS2010 to load the same version of UnitTestFramework .dll as VS2012 when executing the .exe, you would solve the issue there as well. – ThunderGr Nov 24 '12 at 07:30
  • 1
    @ThunderGr Thanks very much for contributing, the OP & I are desperate for some documentation explaining the upgrades in the v 11.0.50727.1 of the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll's. Its not just Moq, other Mocking frameworks have the same problem. IMHO something fishy is happening with the `Embed Interop Types enabled` in VS2010 compared with VS2012, You wouldn't by any chance know the reason? – Jeremy Thompson Nov 24 '12 at 07:37
  • 1
    Perhaps [this question](http://stackoverflow.com/questions/1725210/how-do-i-get-rid-of-api-restriction-unittestframework-dll-already-loaded-error) can help you define a different version for VS2010. Unfortunatelly, MS only realeases information for things they want to, and they do not seem to have released anything about that specific .dll – ThunderGr Nov 24 '12 at 07:57
  • That does not work in this situation. I included the `downloadable repro` in my answer for people to reproduce the problem rather than guess. fyi: thats why I pinged Eric Lippert – Jeremy Thompson Nov 24 '12 at 08:05
  • @JeremyThompson My apologies for the inactivity. The colleague I spoke of actually managed to find the cause and solution to the problem. I haven't had time to write up a good answer, but I was planning to do so shortly. If I haven't done so by the end of this year I will accept your answer :-) – Martin Devillers Dec 27 '12 at 14:16
3

I tried to reproduce this, and for me it doesn't work even in VS 2012.

When you compile a project using "Embed Interop Types", the C# compiler generates an internal type that has only the members you are accessing, and the implementation actually seems to use IDispatch to call the method of the COM object by id.

From your description I understand that your test project in VS 2012 does not access the properties (not even in order to mock them), but the test still succeeds and the generated type in the test project does have these members.

If this is indeed what you are experiencing, can you please look at the content of your test .dll and see how the interop type was generated? You can use a tool such as ildasm.exe.

If the interop type in the test .dll contains all the members, even those you don't access in the test, this may give a clue that the difference is related to the way the interop types are generated in VS 2012.

Also, if you can attach a small minimal VS 2012 solution which reproduces the problem, it may greatly help in diagnosing this.

Ran
  • 5,989
  • 1
  • 24
  • 26
  • I have added a minimal VS solution to my question. My tests run fine in VS2012, but fail in VS2010. The minimal solution show cases this behavior. – Martin Devillers Nov 09 '12 at 07:48
  • 1
    @MartinDevillers I think its an issue with compiler generated code.If you give 0 in place of _rangeMock.Object in Setup, it will pass. Have you checked your assemblies with another browser/ decompiler ILSpy ? as you have mentioned " exception implies that I forgot to setup the appropriate property getter on my mock. " – hridya pv Nov 09 '12 at 09:06
0

First of all check while adding library to the project in VS2010, make sure you created the mock object like

Mock<DocumentService> _mock = new Mock<DocumentService>();

Also .NET 4.0 allows primary interop assemblies to be embedded into your assembly so that you don't need to deploy them alongside your application.Open the properties tab in the assembly in VS2010 and check the Embed Interop types.mkae sure its true.

And to instantiate excel, Excel.Application xlapp = new Excel.Application();

Hope it will work..

hridya pv
  • 1,039
  • 1
  • 7
  • 17
  • Thank you for your answer. However, your answer does not fit the question that was asked. I know how to mock types and I already use Embed Interop Types. The problem lies when using two different assemblies that both have Embed Interop Types enabled. – Martin Devillers Nov 08 '12 at 09:40
  • 1
    Oops..I just read the title and gave the answer, sorry.Will read the whole question now. – hridya pv Nov 09 '12 at 06:24
0

I found that, at least in VS2015, I could still embed the interop types in my assembly under test, but set "Embed" to false on the PIA assembly reference in my test project and I no repro this.

Heath
  • 2,986
  • 18
  • 21