Assuming that you are referring to a table view, then, HideXxxProperty() alone will not cause the column to be hidden. This is because a HideXxx method is dynamic - the hiding may vary between instances and according to the state of the
object. The table-renderer has to assume that some of the objects in its view might have that property visible.

If a property is marked [Hidden] or if the property is rendered invisible to the user via the framework's authorization mechanism, then the column will not be rendered.

I suppose it would be possible to arrange that in a table view where the column was shown then if that property was invisible for a given row then it could be rendered as, say 'Hidden'. (Note that it could not simply be blanked as this could be confused
with the property being null/empty). But this might not be acceptable to all.

Possible workarounds would be:

1. Use a custom view to remove that column in your view.

2. Return the collection as defined by an interface that reveals only the properties of interest.

That did not throw the exception, but again displayed all the properties in the list, not only the ones on the interface.

Besides that, I do not see how explicitly casting could make a difference. The method returns IIndividualListViews. So the calling code will have references to IIndividualListViews whether there was an explicit cast or not. Not so?

"So the calling code will have references to IIndividualListViews whether there was an explicit cast or not. Not so?"

No. The UI is entirely generic so it doesn't know about any of your domain code. The UI simply reflects over the objects that it is being given (that's a simplified explanation, but the principle is right). Even if the method signature
returns X, what the viewer will reflect over is the actual .NET type that is returned (which must conform to X, obviously), which in your code was still in fact a List<Individual>. You could verify that by putting in a break-point and examining
the returned object.

If you think about it, that's always true in .NET - even if a method signature returns type Ixxx, the calling code can still test the actual type of the returned object, and even cast it back to that type (not that that would be good practice,
obviously!)

Ok, that worked. Pity that it is not possible with the IQueryable. I'll have to go with a custom view.

Just FY, the paging still works on the UI with the interface approach above, but obviously it has to load the full recordset from the DB each time.

"No. The UI is entirely generic so it doesn't know about any of your domain code. The UI simply reflects over the objects that it is being given (that's a simplified explanation, but the principle is right). Even if the method signature
returns X, what the viewer will reflect over is the actual .NET type that is returned (which must conform to X, obviously), which in your code was still in fact a List<Individual>. You could verify that by putting in a break-point and examining
the returned object."