Null reference exception setting Entity Framework property

Question

We're getting an inconsistent null reference exception while assigning a non-nullable scalar variable to an Entity Framework domain object property. I understand what a null reference exception is, but I can't understand how you would get one when assigning a non-null value to a property of a non-null EF domain object.

The domain object looks like this:

[DataContract]
[Table("Participant", Schema = "tour")]
public partial class Participant
{
    public Participant()
    {
    }
    [DataMember]
    [Key]
    public int ParticipantID { get; set; }
    ...
    public DateTime? AutopayLastAttemptedUtc { get; set; }
}

The area where we are getting the exception is:

DateTime utcNow = DateTime.UtcNow;
// The below line throws the Null Reference Exception.
participant.AutopayLastAttemptedUtc = utcNow;
ParticipantService.Update(participant);

I still get an exception on the same line if I add some debug code to prove variables are not null:

DateTime utcNow = DateTime.UtcNow;
// This line proves that participant is not null and that
// AutopayLastUpdatedUtc can be read (not that that really
// matters because we only want to set it
TelemetryClient.TrackTrace("Participant", SeverityLevel.Information, new Dictionary<string, string> {
    { "ParticipantId", participant.ParticipantID.ToString() },
    { "AutopayLastUpdatedUtc", participant.AutopayLastAttemptedUtc.ToString() }
});
// The below line throws the Null Reference Exception.
participant.AutopayLastAttemptedUtc = utcNow;
ParticipantService.Update(participant);

I don't understand what could possibly be null

• participant can't be null because we use it in the debug code on the line above
• utcNow can't be null because it's a non-nullable type
• AutopayLastUpdatedUtc is a standard EF setter

Note that I am not asking what a null reference exception is. I am asking how a null reference exception could possibly happen when assigning a non-null value to a property of a non-null object.

Answer 1

Despite having checked this several different ways already, @MartinLiversage was correct that the reported line numbers were off. The exception was actually being thrown by a later line (not shown in the sample code) and was easy to fix once I found the line with the problem.

My test case for reproducing this was on our test server rather than my development machine. That's fairly normal, because the databases are different and it's not always easy to find a database record that triggers the same problem on my development database. It does make debugging harder though. The test server builds with "Define DEBUG constant" set, but it does also have "Optimize code" set, so I wonder if that is what is causing the lines to be incorrectly reported.