.NET

Any .NET development related posts.

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.

Png images and ASP.NET… Getting a “A generic error occurred in GDI+”?

/ James Fitzsimons / Leave a comment

Another one I would have spent hours on was solved in two minutes by the wonder that is the internet. More specifically Chris Garrett over at ASPAlliance explains the solution to the png generic error in GDI+ exception .

The short story is you can’t use the Bitmap Save() method with a non-seekable stream. So, instead of just doing this:

img.Save(context.Response.OutputStream, ImageFormat.Png);

You have to do something like this:

MemoryStream memoryStream = new MemoryStream();
img.Save(memoryStream, ImageFormat.Png);
memoryStream.WriteTo(context.Response.OutputStream);

Cheers Chris, you saved me hours of work!