I am using several BOs which inherit from the same base BO to bind to several different reports.  So for example:

BO1, BO2, and BO3 all inherit from BO.

BO1 is used on Report1, BO2 is used on Report2, and BO3 is used on Report3. 

In all of these cases, the inherited BO is just extended a few more custom properties and fill methods to be used specifically for each of the reports.   I can open the application and run one of these reports without error.  However, if I then try to run another of the three reports I get an error: "Object does not match target type".  So, if I run the app, I can run Report1 successfully but then if I try to run either Report2 or Report3 it will throw the error.  I can still run Report1 as many times as I want.  The same is true no matter what the order.  If I were to run Report2 first, it would run successfully but Report1 and Report3 would give the error. 

This is only happening on reports which are bound to BOs that inherit from the same base BO.  The reports can be run successfully as long as no other report bound to a BO that shares the base BO has been run.  It seems as if something is being shared between the BOs for some reason because they are inheriting from the same base. 

Here is the call stack I get...I have highlighted where I think the relevancy begins for you:

at System.Reflection.RuntimeMethodInfo.CheckConsistency(Object target)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
at MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor.GetValue(Object component)
at DevExpress.Data.Helpers.BaseListDataControllerHelper.GetRowValue(Int32 listSourceRow, Int32 column)
at DevExpress.Data.Storage.DataStorageObjectComparer.CreateStorage(VisibleListSourceRowCollection rows, BaseDataControllerHelper dataHelper, Int32 column)
at DevExpress.Data.Helpers.DataColumnSortInfoCollection.CreateColumnStorages(VisibleListSourceRowCollection visibleListSourceRows, BaseDataControllerHelper helper)
at DevExpress.Data.DataController.DoSortRows()
at DevExpress.Data.DataController.DoRefreshCore(Boolean useRowsKeeper)
at DevExpress.Data.DataController.DoRefresh(Boolean useRowsKeeper)
at DevExpress.Data.DataControllerBase.DoRefresh()
at DevExpress.Data.DataController.OnSortInfoCollectionChanged(Object sender, CollectionChangeEventArgs e)
at DevExpress.Data.NotificationCollectionBase.OnCollectionChanged(CollectionChangeEventArgs e)
at DevExpress.Data.NotificationCollectionBase.EndUpdate()
at DevExpress.Data.Helpers.DataColumnSortInfoCollection.ClearAndAddRange(DataColumnSortInfo[] sortInfos, Int32 groupCount)
at DevExpress.XtraReports.Native.SortedListController.GroupData(DataColumnSortInfo[] sortInfos)
at DevExpress.XtraReports.Native.SortedListController.GroupData(GroupField[] groupFields)
at DevExpress.XtraReports.Native.SortedListController.GroupData(SortedListController listController, XRGroupCollection groupCollection, GroupFieldCollection groupFields)
at DevExpress.XtraReports.UI.XtraReportBase.get_DataBrowser()
at DevExpress.XtraReports.UI.XtraReportBase.BuildDocument(DocumentBuilder builder)
at DevExpress.XtraReports.UI.XtraReport.CreateDocument(PrintingSystem ps, Single progressRange)
at DevExpress.XtraReports.UI.XtraReport.CreateDocument(Single progressRange)
at DevExpress.XtraReports.UI.XtraReport.CreateDocument()
at BBS.Reports.BaseReport.Process(ParmTable ParmTable, ProgressBarControl& ProgressBar) in C:\Cadence 1.1\BBS.Reports\BaseReport.vb:line 215

I have resolved this issue, but wanted to post my explanation for future reference.  Either this is a different issue than what you explained or I didnt fully understand what you were telling me the issue was.  I think I most likely didnt understand it correctly.  Either way, I'm not sure why the upgrade did not resolve it.

Basically I have BaseBO with ChildBO1 and ChildBO2 both inheriting from BaseBO.  ChildBO1 and ChildBO2 both have custom properties named the same thing, and accessing the same field in the data table.  This is creating the issue.  So if I have a custom property in BOTH child BOs like this :

Public ReadOnly Property MyFieldName() as String
  Get
    Return Me.CurrentRow("MyFieldName")
  End Get
End Property

It should really be moved up to the BaseBO as a property there.  I changed it to prevent error if the query doesnt return this custom field:

Public ReadOnly Property MyFieldName() as String
  Get
    If Me.CurrentDataTable.Columns.Contains("MyFieldName") Then
      Return Me.CurrentRow("MyFieldName")
    Else 
      Return ""
    End If
  End Get
End Property

So moving the custom property declaration the child BOs had in common to the base level corrected the issue and allowed me to access it at the child level without error.  However, when I did the upgrade and changed my reports to use custom BBS objects I created, the issue remained.  I thought this was addressed in 1.6.6? 

That was exactly what I was trying to relay but I apparently did not get the point across.  In all of the examples that I gave you I used BO2 and BO2, but the same thing comes into play if the BaseBO ever references this field outside of a strong-typed property and then through a strong-typed property on any downstream call.  So you ultimately got the problem fixed, but it was just in a different object that my examples were stating.

As for this being resolved in 1.6.6, I was referrring to the template having this logic within it.  But the exact same problem would occur if you setup the same scenario.  We could re-evaluate every custom property, on every BO, on every reference...but this would drastically impact performance (in a negative way) as the custom properties only need to be evaluated once.  The problem comes (and this is standard .NET) when inheritance comes into play.  Because through reflection, we have an inherited BO that has a custom property (i.e. MyField) which gets evaluated properly.  But if the BO in which it is inherited ever references this field even through a CurrentRow reference, the BO will have an issue the moment the second BO is brought up as it will try to evaluate that custom property incorrectly (or rather .NET will through reflection).  So by placing the custom property on the lowest common denominator BO that will ever access that property, it will resolve the problem.