Upgraded from 4 to 6.0.2 hitting stack overflow issues caused by collections?

[clanep...@gmail.com]

I've gone over a lot of documentation on this issue, and I don't believe these exceptions are due to circular references.  Just to be sure, I've implemented both the .PreserveReferences() and .MaxDepth() techniques on the mappings causing issues and they are still throwing stack overflow exceptions. However, when I include the .IgnoreAllComplexTypes() to the mapping, it works until our business code can't find the data it expects from those complex types.  I tested this on objects with single Complex members as well as objects with Collections of complex members, and it seems to an issue unique to Collections of Complex types. For example we have models in our project like so:

public class Address
{
     string Line1;
     string Line2;
     string City;
     int PostalCode;
}

public class User
{
     string Name;
     Address PrimaryAddress;
     List<Address> OtherAddresses;
}

with an Entity of User that looks like this:

public partial class User
{
     public User()
     {
          Addresses = new HashSet<Address>();
     }

     public string Name;
     public virtual Address Address;
     public virtual ICollection<Address> OtherAddresses;
}


and when we query the database for a user, we grab all associated addresses as well, and then map the User entity data to our models, and map models to view models. In 4.0 we had no issues with this process. 

After updating, we were hit a ton of issues, most of which I was able to resolve with the conversion documentation on your wiki.  I've not been able to find anything in the documentation, StackOverflow or this Group regarding this issue with mapping member collections, though, so I look forward to any help you can provide.

If you need more examples or information as to what's going on with this issue, I'll be happy to provide.what I can.

[Jimmy Bogard]

Did you go through the 5.0-6.0 upgrade guide on the wiki?

--
You received this message because you are subscribed to the Google Groups "AutoMapper-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to automapper-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[clanep...@gmail.com]

This (https://github.com/AutoMapper/AutoMapper/wiki/5.0-Upgrade-Guide) is the only upgrade guide I found on the wiki, and I followed it in every applicable instance with out Converters and Value Resolvers.  In the cases where we have specific circular references that need to be retained, I included the .PreserveReferences() to those mappings. 

When I continued to get stack overflow exceptions, I considered that maybe Automapper thought of mapping an object with a Lis<[ComplexObjectNameHere]>t to ICollection<[ComplexObjectNameHere]> (and vice versa) was some sort of circular reference, and tried applying PreserveReferences() to those maps as well, but with no improvement.  Then I tried MaxDepth() with depth values ranging from 1-10, also with no improvement. 

Nothing else in the guide I linked makes specific reference to problems with mapping objects with members that are Collections of complex objects, but maybe I followed the wrong guide?  Or I just don't understand how a different section of the guide applies to my current issue?  I have searched for awhile now and created a bunch of test cases and havn't been able to determine any other possible cause for the Stack overflow exceptions, nor determined any solutions that doesn't involve taking each List of objects in a mapped object and mapping each value individually in a loop and adding the result to the Destination object's List member...which frankly is not a viable solution for us as a result of an upgrade. 

If I'm doing something wrong, or missing something in the guide, please let me know.

[jeremy....@googlemail.com]

I'm encountering a similar problem, but more to do with "includebase" rather than collections, although I have a number of collections of complex types too.  Is there any internal diagnostics or tracing that can be switched on so I can at least find out what mappings are being called, because the Call Stack just shows one anonymous method.

[in...@psynergy.co.za]

Impressed with your persistent approach to resolving the problem, and various methods to which I have also tried without avail.

In the end, did you manage to find the cause or did you drop AutoMapper in lieu of a manual approach?