Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 18 | Comments: 87

filter by tags archive

Brail UpdateFixing AmbigiousMatchException for lazy loaded classes

time to read 3 min | 418 words

There is probably a bug in Dynamic Proxy that causes it to output overrides to methods in such a way that when you reflect over the generated types, you get two methods for each overriden methods, instead of a single overriden method. I looked into it in detail a while ago, and I couldn't figure out how to make it work like I expect it to. The code that it generate is verifable, so this is something that the CLR supports, but I am not quite sure that I understand what the semantics for this is.

So, what does this have to do with Brail? NHibernate makes extensive use of DynamicProxy in order to increase performance and to defer loading, which meant that any application using NHibernate had this issue. Now, Brail is a dynamically typed langauge (well, not really, but that is close enough), which means that it uses Reflection to resolve properties and methods that are called. Because of Dynamic Proxy generated what is basicaly a duplicate method, that failed.

At the basic level, it meant that a call like this:


Would turn into:

blog.GetType().GetProperty("Name").GetValue(blog, null);

(This is actually very far from how it is wokring but again, that is close enough to make sure you understand the problem.) Now, GetProperty("Name") woudl throw an AmbigiousMatchException, since it actually found two properties called "Name", one of the original class, and the second on the proxied class.

Why am I boring you with this? The fix for this was fairly simple, but it involved simply replacing the way Boo (which is what Brail is using) type system with my own. The fast that I could do that with roughly 350 LoC is quite amazing to me.  This also means that I can actually preserve the dynamic nature of Brail, but behind the scene generate strongly typed accessors (think Dynamic Methods), which would elevate any concerns about reflection costs.

The code is in the Castle's trunk now, so you can start using it.

More posts in "Brail Update" series:

  1. (25 Feb 2007) Fixing AmbigiousMatchException for lazy loaded classes
  2. (24 Feb 2006) Nullable Parameters


Pierre Henri

Impressive how you explained every single detail ;)

Ayende Rahien

I can't figure out if that was a good or a bad thing...

Comment preview

Comments have been closed on this topic.


  1. Buffer allocation strategies: A possible solution - about one day from now
  2. Buffer allocation strategies: Explaining the solution - 3 days from now
  3. Buffer allocation strategies: Bad usage patterns - 4 days from now
  4. The useless text book algorithms - 5 days from now
  5. Find the bug: The concurrent memory buster - 6 days from now

There are posts all the way to Sep 11, 2015


  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    03 Sep 2015 - The industry at large
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats