This project is read-only.

Strange error

Oct 15, 2012 at 11:46 PM

After upgrade we got the following runtime error in production today.

While adding a new address entity that has an AddressType.

 The best overloaded method match for 'System.Data.Objects.ObjectSet<SmdCoreModel.AddressType>.AddObject(SmdCoreModel.AddressType)' has some invalid arguments

I tried removing the entity from the model and re-adding it. Not sure what else to try.

Oct 16, 2012 at 8:15 AM

Version of Entity Framework, possibly?  Are you working Model First or Code First?  Check that you have EF 5.0 in all projects that are using it.

Oct 16, 2012 at 9:20 AM

Given the other error that you emailed me directly, I suspect now that you've simply got more than one version of one or more of your own assembly in memory.  This is often the explanation when you get these strange .NET errors.

Oct 16, 2012 at 9:50 AM
Edited Oct 16, 2012 at 9:51 AM

I have confirmed EF 5 everywhere.

 

Given the other error that you emailed me directly, I suspect now that you've simply got more than one version of one or more of your own assembly in memory.  This is often the explanation when you get these strange .NET errors.

Not sure about that. It also happens in production. How would I know / solve this? (I know this is probably not NO specific - I mean my own assembly version problem)

Oct 16, 2012 at 12:06 PM

Ok. Found what is causing, it, although I don't understand why.

Quite a while ago, I implemented your suggested pattern:

However, it might be possible to still use the second pattern that I gave. i.e. add a NotPersisted property to AddressDetail of type Customer, but called, for clarity, 'CreatingCustomer'.  Then in Persisting (or Persisted) call CreatingCustomer.Addresses.Add(this).

From discussion: http://nakedobjects.codeplex.com/discussions/361661

This worked fine.

However, for some other reason, I now had to turn on that transient entities be stored on the session. That is what is breaking the above pattern.

When I turn it off, then the above pattern works. But I need the transients on the session for other requirements.

Oct 16, 2012 at 12:44 PM

Well I still think this might be to do with multiple versions of some assembly  -  the store transients on session might just happen to be what surfaces the conflict between the versions.  When you re-deployed  -  did you make sure that you cleaned out any old assemblies from the server?

Oct 16, 2012 at 1:03 PM

I scrubbed and cleaned everything I know how to. Also deleted and readded references.

I use web deploy for production with the option to delete files on server that are not part of the deploy.

I have managed to work around the transients on session requirement. Previously I had a bunch of related entities created in the Created() method.

Now I have moved all that logic to Persisting() methods. All seems good now. And better to have no transients on the session anyway.

As for the original problem scenario, I can't say whether it is something I broke or a framework issue. But I don't think I'm running more than one version of my assembly.