We Keep Coding

assign two classes to a generic constraint at runtime

I want to assign two classes to generic constraint at runtime using an OR condition. I don't know if it is possible or not, as I am relatively new to all this.
public interface IGenericRepository<TEntity> where TEntity : Employee Department
I want to assign TEntity either Employee class or Department class. Employee & Department are my two entities in DbContext. Please help me out on this one. Thank you in advance.

My first recommendation is: Do not use another generic repository on top of Entity Framework, because it already implements one.
In the other hand, I have seen cases where this make sense. If you are in one of those cases, consider using Generic Repository only for the things that you could apply to every single class of your model. As soon as your model object requires an special query, then create it's own repository for it.
for example, it might be that for Department you only do a ListAll(), then use a generic repository.
But let's imagine that for employee you might want to do more complex things, like ListAllEmployessUnderBossThatAreOnHolidays(Employee boss)
Then you could have this structure:
// All model classes inherit from this one
public class ModelObject
{}
public class Employee: ModelObject
{}
public class Department: ModelObject
{}
// This repository could be use for simple model objects that do simple operations
// For example, -ALL- Department operations are simple, and it never requires a
// complex query. So i handle it with this repository to avoid code duplication with
// other model objects that are also simple
public class IGenericRepository<TEntity> where TEntity : ModelObject
{ }
// Employee has some complex queries, so I create a repository for it that might or
// might not inherit from IGenericRepository
public class EmployeeRepository : IGenericRepository<Employee>
{ }

Empty interface or empty base class to use as type parameter constraint

Suppose I have a generic class in C# whose declaration looks like this:
public abstract class DtoQuery<T> where T : class
{ }
Now, the type parameter is intended to always be a "Dto" class. I have a bunch of these, but the "problem" is that they have nothing in common. They all have just a bunch of (distinct) public properties and no methods.
Ideally I would like to make my DtoQuery<T> class accept only such "Dto" classes as its type parameter. So I would either need to create an empty interface IDto or an empty abstract class Dto.
Question: which one should I go with? Note: the Dto classes will never extend anything else or each other!
(P.S. for the curious: I promise I'm not building something extremely stupid and silly, this is utility functionality in a testing project and won't be used for production code).

Let's say you have (for whatever reason), a hierarchy that looks like this:
public class Person { }
public class Employee : Person { }
public class Boss : Person { }
Now imagine, that we don't want a Person to be treated as a DTO - we only want Employee and Boss to be DTOs.
In this situation, it would be impossible to use an abstract class to denote a DTO, as you can only inherit from one parent in C#.
That's an objective reason as to why using an interface is better. Subjectively, interfaces are also better because the purpose of an abstract class is to provide some functionality. Other than that, is has no benefit over an interface.
The rule of thumb is: Always use an interface when you're unsure. Only use an abstract class if you need implementation.

I agree with #Rob's answer, but since you mentioned that "the Dto classes will never extend anything else or each other" I'm going to add another reason that might tip you towards an interface:
If you choose an interface, you can keep it internal. A public class can implement an internal interface, but it cannot extend an internal class. That also means that consumers of your library wouldn't be able to create new DTO types using the same abstract base class.
You also mentioned that this is going to be used in a test project, so you can use the [assembly: InternalsVisibleToAttribute("Name.Of.Test.Project")] attribute to expose it to only your testing assembly.

Extend a model to add methods

I have reverse engineered a MySQL database in a C# desktop app. What I would like to do is extend one of the model classes, so that I can add methods to it to use locally in my application. I don't want to change any properties or anything just. Just get information and calculate things.
The problem is that when I inherit from one of the model classes I get an error about a new discriminator field being in the class but not the database.
Is there a way to do what I want to do?

Given that the model classes are partial, you can just declare your own partial classes to join them:
// Note - needs to be in the same namespace as the auto-generated declaration
public partial class Foo
{
// Add your own methods here, which can refer to the properties declared
// for the same type in the auto-generated code
}
The point of partial classes is that multiple files can contribute source to the same type.

You could try extension methods to accomplish this instead of inheriting and creating a new subtype.
You would "attach" the extension methods to the model class which you generated.

Ignore base class / interfaces completely in entity framework 5 code first

I have the following entity class:
[System.ComponentModel.DataAnnotations.Schema.Table("User")]
public class User: UserBase, IPersistCustom<Entity> { ... }
Depending on the type of hierarchy mapping you use, EF will generate either a descriptor column or split tables. Is there a way to have EF completely ignore the fact that this class inherits from something or implements an interface?
I don't mean just ignoring base class properties.

If you mark your base class(es) as abstract and use table per concrete type approach this may work. Something like;
context.Entity<User>().Map(p =>
{
p.MapInheritedProperties();
p.ToTable("Users");
});
refer to this.

are you looking for this....
fluent API option
modelBuilder.Entity<XYZ>().Ignore(p => p.PropertyName);

How can I utilize EntityCollection of type <Interface> using a partial class with Entity Framework?

I'm using partial classes. One class is generated from EntityFramework. Another class I generate myself so that I can implement an interface. The interface will be used so two libraries/assemblies will not know about each other but will be able to implement the common interface.
My custom interface declares property EntityCollection(ITimesheetLabors) but my EntityFramework generates EntityCollection(TimesheetLabors) so the compiler tells me that my class doesn't implement EntityCollection(ITimesheetLabors) which is understandable. However, what is the best method of making my partial class return the collection of interfaces I desire?
Should the get of my collection property of my partial class return a newly instantiated EntityCollection so that it can cast the concrete types to my interface? It seems a bit of overkill. What am I missing?
public interface ITimesheet //My Interface
{
EntityCollection<ITimesheetLabors> Timesheets {get;set;}
}
public partial class Timesheet//Class generated by Entity Framework
{
EntityCollection<TimesheetLabors> Timesheets {get;set;}
}
public partial class Timesheet : ITimesheet //My Partial Class that implements my interface
{
EntityCollection<ITimesheetLabors> Timesheets {get;set;}
}

EF doesn't support interfaces so the only way is using both original property generated by EF and your interface property which will internally access the generated property.
Btw. your design smells - on the one side you are trying to hide your entities by using interfaces and in the same time you are exposing EntityCollection => you are making your upper layer dependent on EF. The common approach is to do the opposite design - hide EF and use POCOs (interfaces are usually not needed).