We struck a bit of an odd problem today. We had an older ASP.NET 2.0 website we were migrating to ASP.NET 3.5 and one of the pages has a GridView on it. As we use Spring.NET and NHibernated Microsofts new objectdatasource approach for binding the GridView won’t fly so we were using old school databinding. This meant we needed to be able to handle the RowUpdating event in order to persist our changes. The problem was that the RowUpdating event just wasn’t firing.
Eventually we tracked it down to a weird interaction between Spring.NET and the GridView where if we wrapped the GridView in a spring:panel and suppressed dependency injection the event started firing. Of course the new and old values that are supposed to be available in that event handler were still null…
There is obviously a bug with the databinding in the GridView somewhere and it seems Microsoft is aware of the issue, however I wouldn’t hold my breath for a fix to be forthcoming.
Personally I think the new objectdatasource model has some serious drawbacks and the fact that Microsoft haven’t made the effort to ensure that custom databinding still works is a real shame to say the very least!
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=220.127.116.11, 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=18.104.22.168, 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!
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:
#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.
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:
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.
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!