RhinoMocks Stub not retaining value when property shadowed on inheriting interface

I cannot remember having a Sprint like this! First the issue with debugging in VS2008 on Windows7 x64, then the issue with BadImageFormatException throwing when inheritance constraints were applied to a generic method, and now this one!

 

The Problem

 

I was still fixing the tests that had failed after upgrading to Castle.Windsor 2.1 and RhinoMocks 3.6 when I stumble on this one. Basically I had a unit test that passed before I upgraded and as soon as I switched to using the most recent versions of both libraries the test failed.

The issue manifested on a stub for an Interface that inherited from another interface re-implementing a property member with the keyword new (not a recommended approach but necessary because we were handling legacy code). Here is an example of how our interfaces are designed:

public interface INamedObject
{
   string DisplayName {get;set;}
}

public interface IFeature : INamedObject
{
   new string DisplayName {get;set;}
}

There is a base interface that implements a property which is being shadowed by the inheriting interface.

At some point in our unit test we need to access DisplayName by its base interface INamedObject. Something like the following:

 [TestMethod] 
 public void TestMethodThatFails() 
 { 
     var feature = MockRepository.GenerateStub<IFeature>(); 
     feature.DisplayName = "some name";

     Assert.AreEqual("some name", feature.DisplayName); 
     Assert.AreEqual("some name", ((INamedObject)feature).DisplayName); 
 }

It seems that in the previous Castle.DynamicProxy implementation the proxy created for such interface would result in DisplayName being available on both base interface and inheriting interface. With the new version, when we try accessing DisplayName after casting the object to INamedObject we get a null value. The only way to access it is through the inheriting interface.

It is my understanding that this is not the expected behavior for a stub. I would expect it to retain the value as a regular class does when it implements IFeature.

 

A workaround

 

In the end I had to explicitly set DisplayName value on feature by previously casting it to INamedObject, likewise:

 [TestMethod] 
 public void TestMethodThatPasses() 
 { 
     var feature = MockRepository.GenerateStub<IFeature>(); 
     feature.DisplayName = "some name"; 
     ((INamedObject)feature).DisplayName = "some name";

     Assert.AreEqual("some name", feature.DisplayName);
     Assert.AreEqual("some name", ((INamedObject)feature).DisplayName);
 }

It is true that we need to keep up with the evolution of libraries we consume in our projects, but has more tests are created the price we have to pay for this inconsistencies between versions of the same library starts to raise. It is always up to us to assure that the effort is worth it, and in this case, now that I have migrated all the tests, it was not that bad after all. 🙂

Shout it kick it on DotNetKicks.com

BadImageFormatException when debugging interface mocked with RhinoMocks

My last couple of days has been quite hilarious. First there was the issue with not being able to set breakpoints on my tests, and then started having tests that failed one way when executed normally and a different way when I ran them with debugger attached!

 

The Problem

 

Recently I updated the project I am working on to Castle.Windsor version 2.1. Since we are using an abstraction over the container (for resolving purposes only), we had to adapt it to conform with the new restrictions for Resolving dependencies, thus:

public interface IFaroContainer 
{ 
    object Resolve(Type type);  
    object TryResolve(Type type);  
    IEnumerable ResolveAll(Type type);  
    void RegisterTypeIfMissing<TI, T>(bool registerAsSingleton) 
where T : class, TI;
object BuildUp(Type type); }

With the new Castle.Windsor version we have to enforce that our T class implements TI, which makes perfect sense and helps reducing erroneous registration issues that one could perform.

The problem is that when we try to Mock this interface (I am currently using RhinoMocks v3.6) while in debug mode we get a BadImageFormatException:

The problem is that there is a bug in the System.Reflection.Emit

implementation which cause the runtime to emit invalid code for this

scenario.

You can read more here.

 

How I fixed my issue

 

Since I am depending on third party lib Castle.Windsor, I cannot change the way the fluent interface is designed. It seems though that this constraint is enforced only by Castle.Windsor’s fluent interface, if you use standard component registration you will be able to bypass that argument check thus not unleashing the Emit bug.

I just changed my registrations from using the fluent interface to use the traditional AddComponent and the tests started passing!

Shout it kick it on DotNetKicks.com

Why breakpoints do not get hit when targeting x86 on Windows 7 x64?

This is a very particular scenario. It happened to me and cost me over 3 hours to fix it.

 

Background

I am currently working on a fully managed WPF application, that references a certified C# DLL that was purposely compiled targeting x86 platform (part of the certification process I think). Since I recently got an upgrade on my development machine, and I wanted to take full advantage of my 8GB of RAM I ended up installing Windows 7 x64.

Because of the particular x86 certified DLL, I had to force my application to run in a 32bit process, thus, I changed my application build target to x86. This was about one week ago.

Since I am in the middle of a code cleanup and refactoring work item, I did not had the need to debug my source up until three days after I changed that setting, thus moving if to a back drawer on my brain.

Now I get to a point where I actually need a breakpoint, set it on my code, and run my application. The breakpoint does not get it! I then move the breakpoint to the first line of code on my App.xaml.cs constructor. It does not get hit either. Then I rebuild my project, cleanup my bin and obj folders (something could be inconsistent with those files).

 

Got it working

After spending a couple of hours on this, even getting older change sets to see if the issue was a problem with the source code, I re-opened that back drawer and remembered to try to set the target CPU back to any (it would only crash when the actual certified DLL was loaded).

The breakpoint finally got hit!

 

The solution

Obviously this did not make any sense. Since I had elaborated on the issue I was now able to successfully search for what I needed: “vs2008 breakpoint x64 target x86” and this came out as a result:

Debugging x86 application on Windows 7 x64

What happens is that when you install Visual Studio 2008 on Windows 7, the OS will set the compatibility mode to “Windows XP SP3”. All you have to do is to change this setting to “Windows Vista SP2” and your problem will be fixed. :S

Shout it kick it on DotNetKicks.com