IsAsynchronous CslaDataProvider Orcas Beta 2 Error

ixman posted on Tuesday, August 07, 2007

Hi,

We have a strange issue with the CslaDataProvider after the upgrade to Orcas Beta 2.

The problem is the IsAsynchronous property. If we set it to “True” the code breaks in the FilteredBindingList<T>, in the void System.Collections.ICollection.CopyTo(System.Array array, int index) method with an invalid cast exception from object[] to T[]. If we set the property to “False”, the databinding don’t work although the FilteredBindingList<T> is OK. Our BOs use the FilteredBindingList in this case.

If we build the project in Orcas Beta 1 it works just fine. If we take the build from Orcas Beta 1 and run it on the machine with Orcas Beta 2 it crashes. Could be something from the .Net Framework 3.5 Beta 2?

We have something like this in our code:

<csla:CslaDataProvider x:Key="CountriesList"

                             ObjectType="{x:Type SimpleApplicationBase_BusinessObjects_General:SystemManager}"

                             FactoryMethod="GetCountriesCollection"

                             IsAsynchronous="True"

                             IsInitialLoadEnabled="True"/>                                                                          

<csla:CslaDataProvider x:Key="StatesList"

                             ObjectType="{x:Type SimpleApplicationBase_BusinessObjects_General:SystemManager}"

                             FactoryMethod="GetStatesCollection"

                             IsAsynchronous="False"

                                   IsInitialLoadEnabled="True">

                             <csla:CslaDataProvider.FactoryParameters>

                                   <system:Int32>-1</system:Int32>

                             </csla:CslaDataProvider.FactoryParameters>         

      </csla:CslaDataProvider>

Any ideas?

Thanks,

George

RockfordLhotka replied on Tuesday, August 07, 2007

ixman replied on Tuesday, August 07, 2007

Yes, it's called from the factory method like this:

public static Csla.FilteredBindingList<State> GetStatesCollection(int countryId)

Csla.FilteredBindingList<State> newStatesCollection = new Csla.FilteredBindingList<State>(_statesCollection);

newStatesCollection.ApplyFilter("CountryId", countryId);

return newStatesCollection;

RockfordLhotka replied on Tuesday, August 07, 2007

Well, I can repeat the issue easily enough - that's helpful

I think it might be a bug in CSLA, but it doesn't look real easy to fix. It might also be a bug in WPF. Or both.

FilteredBindingList implements IBindingList, which in turn implements ICollection. FBL also implements IList<T>.

It appears that WPF decided to change from favoring IList<T> to IBindingList beween .NET 3.0 and 3.5 (this is my guess anyway).

So they used to call CopyTo(T[]...) and now they call CopyTo(object[]...).

The possible bug in CSLA is that CopyTo(object[]...) delegates to the other overload, and that's clearly not a valid option in this case. Unfortunately, there's no pre-built CopyTo() I can call in this case, so I might have to manually implement the behavior - PITA.

But why would WPF favor calling the less strongly typed method? And why make that change from 3.0 to 3.5? So it could be a bug on their part too.

ixman replied on Tuesday, August 07, 2007

Thank you for the feedback... I'll try to find a workaround...

RockfordLhotka replied on Tuesday, August 07, 2007

The rabbit hole goes deeper.

They didn't used to call CopyTo() at all - this is absolutely a change in 3.5.

I know this, because the CopyTo() implementations in FBL and SBL are both broken and always have been. The casting bug is trivial - the real bug is that the data was copied from _list (the source list) rather than from this (the filtered list).

Can you check out the FBL current code in svn and see if it resolves your issue?

ixman replied on Wednesday, August 08, 2007

It worked. Thank you.