Dynamically Generated Proxies and Missing Namespaces


The DateTimeInput control from DotNetBar used on my current project has a clear button on the calendar.  Clicking this, attempts to set the bound value to null.  When running this in a simple test harness, it worked.  However, running the same code within my project which uses the open source framework Castle Dynamic Proxy 2, resulted in an “Object Reference Not Set” exception deep within the WPF framework.

Debugging through the .NET Framework source code, it eventually became apparent that the PropertyPathWorker class attempts to get the namespace of the bound type.  In our scenario, this happened to be a MeetingProxy which returns null for the following Framework code:

         void DetermineWhetherDBNullIsValid()
            bool result = false;
            PropertyDescriptor pd;
            object item = GetItem(Length - 1); 
            if (item != null && 
                item.GetType().Namespace.StartsWith("System.Data", StringComparison.Ordinal) && 
                ((pd = GetAccessor(Length-1) as PropertyDescriptor) != null)) 
                result = DetermineWhetherDBNullIsValid(item, pd); 
            _isDBNullValidForUpdate = result; 

The Namespace method in the RtType class is below:  

        public override String Namespace




                string ns = Cache.GetNameSpace()
                if (ns == null || ns.Length == 0)

                    return null;


                return ns;



The problem here is that Microsoft has assumed that all types will return a Namespace.  However this does not appear to be the case for our Dynamic Proxies.  Either this assumption is incorrect or the Dynamic Proxy Code should retain the namespace when the Proxies are generated.

 Initial Work Around
Create a pass through property on the data binding class which wrappers the property on the proxied object, e.g.

        public virtual DateTime? CompleteByDate


            get { return Meeting.CompleteByDate; }

            set { Meeting.CompleteByDate = value; }


Final Solution
This morning I updated the source of our copy of the Castle Dynamic Proxy 2 assembly to set namespaces on the generated proxies, so this is no longer a problem.  Now, I must remember to submit this change to the Castle Project!

blog comments powered by Disqus