Sunday, February 05, 2012
Support » Support Forum
Register Login
HomeWhat is NDO?- Executive Overview- NDO for DevelopersHow NDO Works- Persistent Classes- Mapping- Queries- Reverse Engineering- Inheritance, Polymorphism- Distributed ApplicationsLicensingSupport- Support Forum- FAQ- Solutions- Downloads- E-Mail Support- Tutorial VideosOnline ShopContact
Welcome to the NDO support forum!
Please register/login at the site if you want to post a thread. We sometimes copy support mails of common interest to the forum. They appear with anonymous sender. Please post your messages in English language if possible. You can do your posts also in German, we will translate your post and our answer so that all users of the forum can read your posts. The forum software requires that javascript is enabled. Please do not insert licence information or licence keys in forum posts. If you know a good answer to a post of another user, feel free to reply! The forum is monitored. We reserve the right to remove posts we consider not to be useful for other forum users.
Hi Tobias,
the call stack information points you exactly to the code causing the exception. So all you have to do is setting a breakpoint into the GetHashCode methods and step through until the exception occurs. If VS refuses to debug your assembly just make a little change to the source file (inserting a blank and deleting it) and immediately hit F5. This makes VS remember that it is able to debug the business classes code.
BTW: Why do you generate the Guids of your objects by yourself? If you have good reasons to do that, I'd recommend to use the IdGenerationEvent of the pm:
void OnIdGenerationEvent(Type t, ObjectId oid){ Guid g = GetNewGuidForType(t); ((GuidKey)oid.Id).Key = g;}
That you don't have to insert the id field. If you need access to the id, just use NDOObjectId.Id.Value.
As for your GetHashCode method also note, that Guid is a value type, so it will never have the value "null". An uninitialized Guid always has the value Guid.Null.
I'd recommend further not to include the id into your HashCode algorithm because the HashCode of your object changes if your object is getting persistent. That might cause all kinds of trouble. Or you make sure, that your objects always have an id when the Hash Code is computed: Debug.Assert(id != Guid.Null).
Best RegardsMirko
the call stack information points you exactly to the code causing the exception. So all you have to do is setting a breakpoint into the GetHashCode methods and step through until the exception occurs. If VS refuses to debug your assembly just make a little change to the source file (inserting a character and delete it) and immediately hit F5. This makes VS remember that it is able to debug the business classes code.