What could cause an innocent UnitOfWorkScope.Current.Add() to fail?

This same piece of code worked for other entities...

The calling code in my RepositoryBase<TUnitOfWork>:

T newItem = new T();
Mapper.Map<TDto, T>(newItemDto, newItem);
UnitOfWorkScope.Current.Add(newItem); // NullReferenceException here
SaveChanges();

The exception:

[NullReferenceException: Object reference not set to an instance of an object.]
   Mindscape.LightSpeed.<>c__DisplayClass3.<SetInternal>b__1() +78
   Mindscape.LightSpeed.Entity.set_UnitOfWork(IUnitOfWork ) +321
   Mindscape.LightSpeed.UnitOfWork.Add(Entity entity) +113
   ...

That looks like it's trying to wire up an association -- probably you've set the value of an association, and now the entity has joined a unit of work it's looking to see what ID has been allocated to the associated object so that it can populate the corresponding FK field.  But either it's failing to locate the FK field (which would be weird and should cause an error much earlier if it were the case), or the association has been nulled out in the time between being set and the entity joining the UOW (which doesn't *appear* to be the case from your sample, but *might* possibly be happening inside Mapper.Map).

Thanks Ivan, that gave me a direction to look for...

I don't suppose you or anyone else have any tips and tricks on ensuring smooth integration between AutoMapper and LightSpeed? :-)

Ivan,

Assuming my entity is Person and the DTO is PersonDto and I'm trying to create a default Person.

I noticed the following changes to Person before and after calling the Mapper.Map:

1) The simple fields like FirstName and LastName got mapped

2) The through associations like Addresses which originally had its _addresses equals to Null, and after the mapping, it becomes an empty collection (seems odd...)

Does this mean anything to you?  Would something like #2 cause problem?

I don't think #2 would cause problems.  Looking at the code, the scenario I'm thinking of involves a to-one (EntityHolder-based) association.

When you set the value of a to-one association (e.g. Person.House = someHouse), and the new value is not null, and the entities are not part of a UOW, we queue up an action on the Person for when it does join a UOW.  This is required because until the House joins a UOW, it doesn't have an Id, so the FK (Person.HouseId) can be left at 0.  When the Person and House join a UOW, they will have IDs allocated.  So now the Person.HouseId needs to be updated to House.Id.  This is what the queued action does.  And it looks like it will fail with a NRE if Person.House is now null (we checked for null when we decided whether to queue up the action, but we don't check again when we execute the action).

The stack trace seems to show that we're in an anonymous method at the point where the NRE occurs, and the "wire up key" queued action is the only anonymous method I can find in the right place.

So check what Mapper.Map is doing to any to-one associations.  That's the only thing I can think of that would be causing the error you're seeing.

The Person entity has a couple of those attributes like PersonType (not nullable) and PersonStatus (nullable).

I first retrieved a PersonTypeDto and then assigned it to the PersonDto.PersonType (note: PersonDto doesn't have a PersonTypeId).  I'm wondering if it is safe to run Mapper.Map using that since the newly created Person would have a null PersonType...

Since the problem appears to be with objects that are being modified outside a UOW and then being joined to a UOW, have you considered just doing the IUnitOfWork.Add *before* doing the Mapper.Map?

Thanks! That solved one of the problem, the first occurrence of that NullReferenceException.

Now I need to figure out how to make the subsequent occurrences disappears too.  These subsequent exceptions are most likely caused by reason you mentioned earlier re the ID.