Sorry, my stupid mistake. I don't know what I was smoking yesterday but after a good nights sleep I am clearer now.
@rhughes pointed out (see note below) it was the new() constraint that was stopping the Generic definition from taking interfaces, which was a good suggestion. I did try it but Entity Framework (EF) won't work with interfaces (known design point) so I stayed with real classes in my Generic definition, i.e.
private IMyService<MyData, MyDto>
To use my generic services with EF I will have to relax my design goal of only passing interfaces between layers. However, on balance, the gain of the generic services and the fact that the classes are normally just data means I am OK about relaxing my rule of only passing interfaces between layers in these cases.
Also a few people have asked why I even need a generic in the example I put up. I should explain that as it was a interface issue I removed some code to make the question simpler (The code was rather long). In fact the signature of the service included a generic class as a constraint for the TDto part. The full definition is:
public class MyService<TData, TDto> : IMyService<TData, TDto>
where TData : class, new()
where TDto : GenericDto<TData, TDto>, new()
The GenericDto is an abstract class which contains a number of methods for transforming data for TData->TDto and TDto->TData. These default methods use AutoMapper and below is an example of building a list query to take a EF class and transform it to an IQueryable TDto:
internal virtual IQueryable<TDto> BuildListQueryUntracked(TemplateWebAppDb context)
{
Mapper.CreateMap<TData, TDto>();
return context.Set<TData>().AsNoTracking().Project().To<TDto>();
}
These default transformations can be overridden by the actual Dto class when the transform is too complicated for AutoMapper. However I should say I have found AutoMapper pretty good, especially now that it can project to IQueryable.
Thanks for everybody's help and sorry about the brain freeze on my part.