c# - EF Code First - Property of type Type

Question

I have an object that has a property of type Type:

public ScheduledJob
{
    public int ID { get; set; }
    public Type JobType { get; set; }
    public string JobParameters { get; set; }
}

When I generate the code-first migrations, I get the following error:

System.ArgumentNullException: Value cannot be null.
Parameter name: key
    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
    at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
    at System.Data.Entity.ModelConfiguration.Configuration.Mapping.SortedEntityTypeIndex.Add(EdmEntitySet entitySet, EdmEntityType entityType)
    at System.Data.Entity.ModelConfiguration.Configuration.Mapping.EntityMappingService.Analyze()
    at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.ConfigureEntityTypes(DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest)
    at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.Configure(DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest)
    at System.Data.Entity.DbModelBuilder.Build(DbProviderManifest providerManifest, DbProviderInfo providerInfo)
    at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection)
    at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)
    at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)
    at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
    at System.Data.Entity.Internal.LazyInternalContext.get_CodeFirstModel()
    at System.Data.Entity.Infrastructure.EdmxWriter.WriteEdmx(DbContext context, XmlWriter writer)
    at System.Data.Entity.Migrations.Extensions.DbContextExtensions.<>c__DisplayClass1.<GetModel>b__0(XmlWriter w)
    at System.Data.Entity.Migrations.Extensions.DbContextExtensions.GetModel(Action`1 writeXml)
    at System.Data.Entity.Migrations.Extensions.DbContextExtensions.GetModel(DbContext context)
    at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration, DbContext usersContext)
    at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration)
    at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.GetMigrator()
    at System.Data.Entity.Migrations.Design.ToolingFacade.GetPendingMigrationsRunner.RunCore()
    at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.Run()

What is the best way to make this scenario work?

Edit for @NSGaga's post:

The whole model (simplified) is this:

All job objects implement the following interface:

public interface IJob
{
    Guid ID { get; set; }
    void Run();
}

Each of the jobs has its own properties used as a sort of parameter:

public class ProcessMedia : IJob
{
    public Guid ID { get; set; }

    public int MediaContentID { get; set; }

    public void Run()
    {
        if(MediaContentID <= 0)
             throw new Exception("Missing parameter MediaContentID");
        //work
    }
}

I use this model for an asynchronous job processing system, which works fine. Now, I'm trying to build a scheduler, where I can give it a job type and parameters (serialized to string) and have it run on intervals.

Answer 1

Take a look at this post I made few days ago...

How should I define a field that can take various data types in EF?

Why are you doing this ?

You almost never need to save the Type as such.

@David mentioned already what to do.

But I'd further discourage you to go that way - but rather rethink.

The EF code first is about having 'strong-typed' entities. You can have nice 'inheritance' working, w/o a need to save a Type.

If you need something like an 'enum type' out of a limited # - use an enum or an int.

You can post your model and I'll point you out if it could be changed.

---

I think you could use inheritance for what you need.
Make different types of Jobs entities.

e.g. take a look at this solution here (my post earlier)
Multiple Inheritance Levels in EF Code Firs
...and let me know if problems, questions when you try something.

Maybe it's easier to use TPH (like it's in there), they all get stored in the same table - and you get less problems usually.