David McDermott

I believe this is a bug because the behavior of ```SerializationInfo.AddValue(T)``` will have no issues about assembly version, but ```SerializationInfo.AddValue(MobileList)``` will fail.

We actually don't use SerializationInfo.AddChild() anywhere in our code. Should we only be using AddValue() on system types? Is the code below correct? ``` public AvailableMigrationPackageInfo Test { get; set;...

I agree, there are fundamental versioning decisions that need to be made when a type's properties aren't matching up. I can see that the assembly version is also important even...

I think the conclusion is as follows: 1. Add an option to turn on assembly/type matching somewhere in the CSLA options (default setting is off) 2. Change SerilizationInfo so it...

Number 4: Apparently we are not using the SerializationInfo correctly. We add all of an object's properties using info.AddValue function regardless of if the value is a custom type or...

@kumarlamichhane Do you get similar results for translated images?

It appears that "arrow" equipment which might be a special case but it's in 3 different categories. "adventuring-gear", "ammunition", and "standard-gear". So I would actually suggest that "equipment_category" becomes a...

I'm running into this issue as well, and I have not found a work around yet. Is any progress being made on this issue?

This is my solution after spending hours digging through dapper code. First I set the defaults of the StronglyTypedId through the StronglyTypedIdDefaults. I put this code in some central file,...

I think it's not that clunky it's like the primary equipment category and then the set of secondary categories. I have not thought of all of the downstream effects this...