Am I doing something wrong, or is this a subtle bug?

Consider:

<llblgenpro:LLBLGenProDataSource 
ID="llbDataSource" 
runat="server" 
DataContainerType="EntityCollection" 
EntityCollectionTypeName="Talisman.CorpScorecard.Domain.MetricScorecardCollection, Talisman.CorpScorecard.Domain"
LivePersistence="True" 
ThrowExceptionOnIllegalFieldInput="true" />

<llblgenpro:LLBLGenProDataSource 
ID="llbDataSource" 
runat="server" 
DataContainerType="EntityCollection"  
EntityCollectionTypeName="Talisman.CorpScorecard.Domain.CollectionClasses.MetricScorecardCollection, Talisman.CorpScorecard.Domain" 
LivePersistence="true"  
ThrowExceptionOnIllegalFieldInput="True" />

The first declaration is missing the .CollectionClasses, and when bound to a GridView, ie:

<asp:GridView ID="gridMain" runat="server"ID="llbDataSource" EmptyDataText="No data found."

I always just got the output "No Data Found."

When I set tracing "SqlServerDQE" value="4", and do a compare with the correct vs incorrect declaration, with the incorrect declaration, there is no select generated at all. Which I suppose makes sense somewhat, because it is an incorrect declaration.

But I would expect in this situation to get at least a huge runtime error, but there were no complaints at all. Why is that?

Which LLBLGen runtime library verison/build number are you using?

2.6 Final. I'm quite sure I'm working with the most latest downloaded libraries.

I should note how I came about this bug, which might explain why it's never been encountered before. I've been working with David Elizondo on LLB templates for ascx controls, and I missed the .CollectionClasses in one of the templates. Someone just dropping a LLB data control onto a form would never encounter this situation.

It doesn't throw an exception indeed, it silently ignores the type. It's been this way for a long time, and although I can find back the point when we wrote the code, I can't find back the reason why it doesn't throw an exception in the current code, other than I find it logical it doesn't throw an exception because it's possible to set the collection at runtime, plus it might be the case that there's no type set yet during design time which causes the designer to show an area which threw an exception, instead of the control itself.

So I'm a little reluctant to make a change in this area, although I understand it might be a problem to track down.

I can see it not throwing an exception if no type is set, that makes sense to me, but if an invalid type has been specified, I can't see how this wouldn't be considered worthy of an exception.

I doubt many people encounter this situation, but when it happens to you, it makes you think you are starting to go insane.

I see your point, yet it's still a breaking change (as for example currently a page works properly if the collection type is wrong (or in adapter, the factory) however the developer has set the entity collection property to a valid instance.

So we'll add the exception throwing to v3, and document the breaking change.