Hi Viktor,
Your suggestion works, but it is not ideal in my scenario. In our actual system, the IQueryable<> object is handed out to a "builder" that is responsible for attaching the criteria as well as the projection into custom DTOs, based on various configuration and other user input. As you noted, your approach is applicable "if this is the complete query", which it is not. My example here is an isolation of what I determined to be the point of failure after the builder has done its job.
In fact, the Where criteria is not even important to the failure, it appears to just be an issue with the projection. The following is sufficient to cause the failure:
var query = from t incontext.GetAll<Teacher>() select new { Teacher = t, Person = t asPerson };
The builder is a separate component, and not wholly in our control. Changes would be a significant undertaking. As a result, I wanted to pursue the problem from the Telerik side, too. On the surface, the query does not seem unreasonable, if a little contrived - is there anything I could do with container settings that would permit this query to run exactly as I presented it?
Thanks,
Paul