Entity Framework TimeSpan - Time Error

Question

I am using EF 5 and c#.

In my Main Project i use CodeFirst to Create my Database. There i got this Entity:

    public class Shift {
    public string Name { get; set; }
    public TimeSpan StartTime { get; set; }
    public TimeSpan EndTime { get; set; }
    }

The TimeSpan Properties are created as time(7), not null in the Database.

In my MainProject everthing works proper.

But when accessing the Database from a Windows Service Project ( I use the same Context & Models from the Mainproject) in the same Solution i receive this error:

This line (Multiple times used in the Mainproject):

context.Shifts.Load();

results in

There is no store type corresponding to the conceptual side type 'Edm.Time(Nullable=True,DefaultValue=,Precision=)' of primitive type 'Time'.

What is the cause of that issue?

//edit

The funny thing is our main project created the time Column without our helo.

i replaced the App.Config file of the Service with the config from our mainproject and now it works?

I still wonder why tough...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
  </configSections>
  <connectionStrings>
    <add name="DevConnectionString" connectionString="Data Source=xxxxxxIntegrated Security=True" providerName="System.Data.SqlClient" />
    <add name="Properties.Settings.DevConnectionString" connectionString="Integrated Security=TrueMultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  </entityFramework>
  <log4net>
    <root>
      <level value="DEBUG" />
      <appender-ref ref="LogFileAppender" />
    </root>
    <appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender">
      <param name="File" value="log\Error.log" />
      <param name="AppendToFile" value="true" />
      <rollingStyle value="Size" />
      <maxSizeRollBackups value="10" />
      <maximumFileSize value="10MB" />
      <staticLogFileName value="true" />
      <layout type="log4net.Layout.PatternLayout">
        <param name="ConversionPattern" value="%n%-5p %d{yyyy-MM-dd hh:mm:ss} – %m%n" />
      </layout>
    </appender>
  </log4net>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Windows.Interactivity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="4.5.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Answer 1

Entity Framework version 5 doesn’t map timespan. But ou can use a workaround to use it anyway.

Just store the timespan as TimeSpan for manipulation and as an Int64 for mapping

public Int64 TimeSpanTicks{ get; set; }     
[NotMapped]
public TimeSpan TimeSpanValue
{
    get { return TimeSpan.FromTicks(TimeSpanTicks); }
    set { TimeSpanTicks= value.Ticks; }
}

Answer 2

Your issue might be explained by your SqlServer version.

Entity Framework 5 does support TimeSpan. It uses time as the Sql backing type. Support for the time type began with SqlServer 2008. Is it possible that you switched from a SqlServer 2005 instance to 08 or newer? That would result in everything suddenly working as you experienced.

It's worth mentioning that using TimeSpan with EF can be problematic as the backing type of time(7) will only hold a Timespan that is <24h in length. Therefore it is common to use the workaround mentioned by floAr.