Limit type of generic injected into class

I'm wondering if something like this is possible in .NET6.

Given an application with 3 more databases, each using its own DbContext, create a generic DbContext over an entity like so:

public class DbRepository<TRepository, TEntity> : IDbRepository<TRepository, TEntity> where TRepository : IContext

services.AddScoped(typeof(IDbRepository<,>), typeof(DbRepository<,>));

With implementations:

public class FirstDbContext : IFirstDbContext
public class SecondDbContext : ISecondDbContext

Now a BaseService that is also of the same TRepository:

public class BaseService<TRepository> where TRepository : IContext

Can I limit what is passed into a Service based on the TRepository in BaseService?

So That:

public class UserService : BaseService<IFirstDbContext>
{
    public UserService(
        IDbRepository<IFirstDbContext, User>  userDbRepository, /* allowed */
        IDbRepository<ISecondDbContext, Invoice> invoiceDbRepository, /* not allowed */
    ) { }
}

If UserService is defined with BaseService<IFirstDbContext> then only allow injection of types IDbRepository<IFirstDbContext, TEntity>.

No, at least using language type system. The only thing you can do - write custom Roslyn analyzer which will process your files and emit corresponding warnings/errors.

> Can I limit what is passed into a Service based on the TRepository in BaseService?

Yes - ish.

A common technique (well, at least for me) is to add a marker interface to all of my EF entity class types so that I can add it as a generic-type-parameter-constraint as a sanity-check in generic methods that I write over, say, DbSet<T>, to ensure T is an actual EF entity class type rather than any-ol'-.NET-type (after-all, using DbSet<String> will compile, even though that's just silly) - usually this just looks like interface IEntity {}.

(For a somewhat relevant example, see how I use interface IPart in my answer to this other QA)

I'd like to stress that this IEntity type is not foolproof: it's entirely possible for downstream consumers to implement IEntity themselves and pass their types into the constrained generic methods and break things - but that's not something we're worried about at this point.

Moving on, first, let's ditch the interface types for each DbContext (i.e. IFirstDbContext and ISecondDbContext): that's just unnecessary: instead of specifying IFirstDbContext just specify FirstDbContext directly (though if you really want to keep those interfaces and use them, you can - but you're just creating extra legwork for yourself; you're never going to need to mock a DbContext so I just don't see the point in having an interface for a DbContext type (excepting some kind of IReadOnlyDbContext, but that's another topic).

Considering the interface IEntity So let's generalize that out to a single generic interface:

interface IEntity<TContext>
    where TContext : DbContext
{
}

...then add that interface to your entity types: User, Invoice, and Some2ndDbContextEntity:

partial class User : IEntity<FirstDbContext>
{
}

partial class Invoice : IEntity<FirstDbContext>
{
}

partial class Some2ndDbContextEntity: IEntity<SecondDbContext>
{
}

_{I'm very opposed to the concept of generic-repositories, so I'm only re-using the OP's IDbRepository<TContext,TEntity> interface here to illustrate the point I'm making - and not as an example of how C# programs should be written.}

So let's modify your IDbRepository to add some constraints:

interface IDbRepository<TContext,TEntity>
    where TContext : DbContext 
    where TEntity  : class, IEntity<TContext>
{
}

So then inside UsersService we can now use IDbRepository<,>:

class GoodUserService
{
    public GoodUserService(
        IDbRepository<FirstDbContext,User>    usersRepository,
        IDbRepository<FirstDbContext,Invoice> invoicesRepository
    )
    {
    }
}

...but if we try to use IDbRepository for Invoice with SecondDbContext - or for Some2ndDbContextEntity with FirstDbContext then the generic constraints will be violated:

class BadUserService
{
    public BadUserService(
        IDbRepository<FirstDbContext,User                  > usersRepository,
        IDbRepository<FirstDbContext,Some2ndDbContextEntity> badRepository
    )
    {
    }
}

Indeed, we see a compile-time error if we do that: