.net

NMock and out parameters

/ James Fitzsimons / 2 Comments

While trying to create a unit test the other day I came across the situation where my mock object needed to return a value via an Out parameter. A quick google turned up this post over at dev:ices.

I thought that had answered all my questions but when I tried it I kept getting a very unhelpful error:

—— Test started: Assembly: Tests.dll ——

TestCase ‘Tests.BatchOrderMessageHandlerTests.TestNMock’
failed: NMock2.Internal.ExpectationException : unexpected invocation of foo.DoFoo(, , out)
Expected:
1 time: foo.DoFoo(equal to , equal to , equal to ), will set c=, return [called 0 times]
at NMock2.Mockery.FailUnexpectedInvocation(Invocation invocation)
at NMock2.Mockery.Dispatch(Invocation invocation)
at NMock2.Mockery.MockObject.Invoke(Invocation invocation)
at NMock2.Monitoring.Invoker.Invoke(Invocation invocation)
at NMock2.Monitoring.ProxiedObjectIdentity.Invoke(Invocation invocation)
at NMock2.Monitoring.ProxyInvokableAdapter.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Tests.BatchOrderMessageHandlerTests.IFoo.DoFoo(Int32 a, Int32 b, Int32& c)
C:svnGLGParnters.TradeIdeasPositionManagersrcTestsBatchOrderMessageHandlerTests.cs(136,0): at Tests.BatchOrderMessageHandlerTests.TestNMock()

0 passed, 1 failed, 0 skipped, took 0.77 seconds.

A bit confused I quickly whipped up a trivial test as my unit test was a bit complicated and returned an enum as the Out parameter. My hypothesis was that NMocks couldn’t return an enum as an Out parameter.

public interface IFoo
{
int DoFoo(int a, int b, out int c);
}

[Test]
public void TestNMock()
{
IFoo foo = _mockery.NewMock();

Expect.Once.On(foo).Method(“DoFoo”)
.With(1, 1, Is.Out)
.Will(new SetNamedParameterAction(“c”, 2), Return.Value(1));

int result = 0;
int a = foo.DoFoo(1, 1, out result);

_mockery.VerifyAllExpectationsHaveBeenMet();
Assert.AreEqual(2, result);
}

This also failed so I checked what version of NMocks I was using. My NMock2.dll assembly had a revision number of 1.0.2313.18049. I downloaded the latest binaries from the NMock website. Checking the version number of the latest build shows it to be 2.0.0.44.

Rerunning the unit tests against this version of the NMock library everything now works!

So, if you’re having trouble with out parameters in your NMock mocks, upgrade your build version.

NHibernate 2.0 and the join table syntax

/ James Fitzsimons / 11 Comments

I’ve noticed my post on Mapping a view with NHibernate is always quite popular. Resorting to mapping from a view has worked fine in the past as long as you only required read access, but if you wanted to build a complex object relational mapping that you could update you were in trouble…

Until Now

With NHibernate 2.0 recently being released we now have access to the join table syntax in our mapping documents. This means we can now build more sophisticated domain objects that map on to more than one table. NHibernate takes care of the multi-table inserts and updates behind the scenes making your life easier.

This has to be one of the most underrated features of NHibernate 2.0 as it finally allows you to break away from the one to one mapping between domain objects and your relational model which has ultimately caused compromises in the past.

I urge you to check out this and the other fantastic new features available in the latest NHibernate release.

Avoid cryptic errors with Setter injection and Spring.Net

/ James Fitzsimons / Leave a comment

Today I found out about a really neat feature in the Spring.Net framework that can help enormously with debugging Spring.Net configuration problems.

If you are using setter injection and have properties that need to be set (why aren’t you using constructor injection?) then you should decorate those properties with the [Required] attribute. You then need to add a built in post processor to your application configuration like so:
<object type=”Spring.Objects.Factory.Attributes.RequiredAttributeObjectPostProcessor, Spring.Core”><object/>

Now if you forget to configure one of your required properties instead of getting a cryptic dependancy error like this:

Spring.Objects.Factory.ObjectCreationException: Error thrown by a dependency of object ‘myWidget’ defined in ‘assembly [Widgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null], resource [Widgets.application-config.xml]’ : Initialization of object failed : Object reference not set to an instance of an object.
while resolving ‘constructor argument’ to ‘otherWidget’ defined in ‘assembly [Widgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null], resource [Widgets.application-config.xml]

You get a nice helpful error like this:

Spring.Objects.Factory.ObjectInitializationException: Property ‘OtherWidget’ required for object ‘myWidget’

Much more helpful!

Mono bugs fixed; Spring.Net support coming soon!

/ James Fitzsimons / Leave a comment

I’ve managed to get all my Mono patches committed in time for 2.0 which be released very soon. Bugs I’ve fixed are:

#325128 ConfigurationSection.GetRuntimeObject
#395209 Fix incompatibility in the HierarchicaDataBoundControl
#397612 Mutually exclusive behaviour between Mono and MS.NET for xs:import

As well as a couple of other fixes I didn’t create bugzilla bugs for:
The TypeDescriptor bug which I blogged about a while ago, and another XmlSchema bug where Uri.OriginalString wasn’t being returned in the correct case.

Hopefully with these Mono bugs fixed in the latest release the major barriers to getting Spring.Net support finished and committed in will be removed. I’m in the process of working through my patch with Mark Pollack, so all going well we may see some Mono support in the next Spring.Net release.

Patching Mono

/ James Fitzsimons / Leave a comment

I submitted a fix for bug #325128 last night which was the last of the four patches needed get Spring.Net working on the Mono runtime. So far I’ve submitted patches for:

  • TypeDescriptor

  • XmlSchema

  • HierarchicalDataBoundControl

  • ConigurationSection

So far only the TypeDescriptor patch has been accepted and committed to the repository, but hopefully the other three won’t be far behind. It’s quite important to us that these patches make it into the 2.0 release so we can just use the official builds rather than having to build from source ourselves.

Spring.NET on Mono

/ James Fitzsimons / Leave a comment

It’s been a while since my last post because I’ve been extremely busy hacking away to get Spring.NET working on Mono. I’ve basically got a working solution now so we should hopefully get the changes committed back into the Spring.NET repositories in the next couple of weeks.

It’s been a bit of an interesting road so far – transistioning our application onto Mono – and I am a bit surprised at how many framework bugs I’ve discovered. I’ve submitted one patch so far for a very minor bug in the TypeDescriptor class, however I still have three more patches to write and submit at this point. I wouldn’t have thought that the parts of the framework we are using were especially esoteric but perhaps I’m wrong.

Now all I need is stepping debugger integration in MonoDevelop and I won’t have to boot into Vista ever again!

Compiling for .net 1.1 framework without VS 2003

/ James Fitzsimons / Leave a comment

I got asked about this by a collegue the other day and it amazed me how many people seemed to be asking the same question on the internet with no helpful answers. The standard response seems to be you need some thing called MsBee!?

No you don’t

You have the only tool you require already installed on your workstation, specificlly csc.exe aka the C# compiler.

All you need to do is open a command prompt and set your path:

path=%path%;c:WINDOWSMicrosoft.NETFrameworkv1.1.4322

and then compile your project:

csc /target:exe out:myprogram.exe *.cs

If your project structure is too complex for a simple command line compile then I suggest you learn a decent .NET build tool.

Mapping view with Nhibernate

/ James Fitzsimons / 6 Comments

Something we’ve come up against in the last week is a need to map a view in Nhibernate. We have a reasonably complex data model with a hierarchical structure involving about four different tables that we wanted to represent as a single mapped entity in our object model. The obvious approach was to define the appropriate view and map that.

No joined tables in Nhibernate:

There seems to be some confusion on the web with a lot of people complaining that Nhibernate doesn’t yet support the joined tables syntax that is available in Hibernate 3.0. While this is true, it doesn’t prevent you from working with a database view as long as you don’t need to update the underlying tables via Nhibernate.

The solution:

Map the view just as you would map any other table in your data model with the standard syntax:

<class name=”MyEntity” table=”MyView”/>

The only other change you need to make is in your property mapping. Add the update and insert attributes to ensure Nhibernate doesn’t try and generate insert and update statements for your view.

<property name=”MyProperty” type=”String” column name=”MyColumn” length=”300″ sql-type=”varchar” not-null=”true”update=”false” insert=”false”/>

That is probably obvious to most people, but there seemed to be enough confusion when I was searching about it that it seems worth stating it again here.

The zen of problem solving.

/ James Fitzsimons / Leave a comment

Sometimes I can be an angry coder. I get stuck on a problem I convince myself ought to be trivial and I get extremely worked up to the point where I feel like breaking something. This happened to me tonight when I was trying to figure out why a custom ASP.NET server control wasn’t working as expected.

Long story short – I spent an embarrassing amount of time thrashing around on the net trying to find answers to a non existent problem. Two minutes, literally two minutes after I’d given up and had packed up for the night I realised what the problem was!

The answer was to simply step back a bit from the problem and relax. The lesson: Bring a little zen to your problem solving and you’re likely to be a far more productive and stress free programmer.

And no, I’m not going to tell you what the problem was – it’s simply too embarrassing.

Url Rewriting and the dreaded “Cannot use a leading .. to exit above the top directory”

/ James Fitzsimons / 6 Comments

I’ve just had a fun couple of hours trying to figure out why my site suddenly starting giving me this exception:

Exception type: HttpException
Exception message: Cannot use a leading .. to exit above the top directory.

It turns out that ASP.NET 2.0 doesn’t like playing nicely with Url Rewriters. The problem occurs when the rewriting rebases the form action path. e.g instead of having your form tag look something like this:

<form id=form1 method=”post” action=”page.aspx?id=whatever” name=”form1″>

After rewriting it ends up looking like this:

<form id=form1 method=”post” action=”../page.aspx?id=whatever” name=”form1″>

This obviously is not a good thing. For a detailed breakdown of the problem I suggest you read sgerz’s post Get GoogleBot to crash your .NET 2.0 site.

In my particular case I am using an open source url rewriter solution from http://urlrewriter.net. Of course the beauty of it being open source is that you can fix the problem! So a one line change on line 80 of HttpContextFacade.cs from:

HttpContext.Current.RewritePath(url, false);

to

HttpContext.Current.RewritePath(url, true);

solved the problem.

So why did this start happening all of a sudden? I can only surmise that it had something to do with the fact that I had just installed Vista SP1 and that caused cassini to start behaving as IIS 6.0 does.

I’ll be emailing the maintainers of the project to see if they want to make the change to the main repository.