ID

Uploaded

Status

Description

Work Items

Action

5328
by mighty_man
Feb 22, 2010
12:37 PM

Being evaluated

Logo original and overview/guide pdf, as zip.

Download

5327
by mighty_man
Feb 22, 2010
7:33 AM

Being evaluated

A patch containing the automapper logo and icon in .ai format, and a overview/guide pdf showing usage.

Download

4710
by wes_mcclure
Dec 22, 2009
4:38 AM

Being evaluated

HasMap suggestion for IMappingEngine. This will tell a client if a mapping is registered. I tried to keep the existing code structure for IMappingEngineRunner.Map by coming up with a set of result selectors, one for HasMap and one for regular Map calls. This might be more complicated than it is worth but allowed me to share code for Map and HasMap all the way through to a result. I'm not sure if re-using the code this way is worthwhile, it seems rather complex, go refactor crazy if you like :) I have included a few tests that you might want to reformat to your NBehave style, these were just copied from my reflection based implementation and setup to run NUnit style.

Download

4201
by SanderSaares2
Oct 22, 2009
9:16 AM

Being evaluated

Port of AutoMapper to Silverlight 3. Changes in functionality:
* no IDataReader support (does not exist in Silverlight);
* no IListSource support (does not exist in Silverlight);
* no mapping to interfaces (dependency on LinFu.DynamicProxy, which has no official Silverlight port; however, some fast experimentation did indicate that it can be ported rather easily, so someone who misses this functionality might want to consider creating and maintaining such a port);
* no unit tests (dependencies do not exist in Silverlight; too big codebase for rewriting; maybe someone will be motivated enough in the future);
* no samples (were dependent on various .NET libraries, once again; not worth porting);
* no benchmark (not worth porting at the moment).

I did not immediately see any reason it would not be compatible with Silverlight 2 but since I don't often use v2 anymore, I didn't spend any time verifying that, so you may consider this a Silverlight 3 port.

Very few changes had to be done code-wise. Mostly just removing the various unsupported pieces and components that had external dependencies.

I've used it in practice and have not noticed any errors. I have not used many advanced features, though. Since the unit tests are heavily dependent on 3rd party .NET libraries, they could not be ported.

I'm not much of a SVN guy and its patch functionality seemed to be unable to cope with some mismatched UTF-8 byte order marks, so I've attached two zip files: one with a clean copy of the ported code and another with huge amounts of SVN junk in there, so you can easily check it in and compare and whatnot.

Enjoy!

Download

6763
by Valeriob
Sep 14, 2010
8:02 PM

Applied

Commenting out ResolutionContext.cs line 210 enables the test. I've been working with AutoMapper for few weeks, i don't know if this patch will break any other test, but i'm finally able to map Self Tracking Entities.

Valeriob wrote Sep 8 at 1:18 AM
I found out that the lookup in the Dictionary<ResolutionContext, object> InstanceCache fails to find other instances because the GetHashCode() functions return different values for the same instance, this breaks rules where Equals and GetHashCodes should give back consistent values for the same pair of objects. This is broken due to hashcode formula using
result = (result*397) ^ (ArrayIndex.HasValue ? ArrayIndex.Value : 0);
Not matching this instance brings Automapper to use the wrong ITypeMapObjectMapper ( NewObjectPropertyMapMappingStrategy instead of CacheMappingStrategy). So when is ArrayIndex set? this happens inside the EnumerableMapperBase<TEnumerable> that in a loop calls CreateElementContext.
Since ArrayIndex is only used inside ResolutionContext.MemberName maybe is not that important to keep it in the GetHashCode math.


Applied Nov 3, 2010: Cause it works. Thanks!

Download

5274
by kfinley
Feb 15, 2010
6:12 PM

Applied

We ran into an issue with the DataReaderMapper class. In our setup we are not using the Mapper static class and instead have a per user instance of the class. Reason is because we need to change mappings several times because we map from an IDataReader to the same type in various situations where the mapping needs to be different. Because AutoMapper currently doesn't support storing multiple maps for the same types we have to call Mapper.Reset() before mapping to a type to ensure the correct type of mapping is used. When we changed to our own Mapper we found a bug with DataReaderMapper because it is using the static Mapper class to retrieve TypeMaps. Since we aren't using the Static Mapper class the configuration TypeMap collection knows nothing about our maps and we get null reference exceptions.

The solution was to change this line:
var configurationProvider = ((MappingEngine)(Mapper.Engine)).ConfigurationProvider;

To this:
var configurationProvider = mapper.ConfigurationProvider;

This way the same Configuration is used to resolve types for the DataReaderMapper.

A better solution would be to add support for multiple mappings for the same type (Work Item # 4036).

Thanks,
Kyle Finley


Applied Feb 18, 2010: This one's fixed in 1.0.1.160, which you can find on the teamcity.codebetter.com site. Thanks for the patch!

Download

4658
by enghamed
Dec 14, 2009
5:13 PM

Applied

Solve for the Error mapping IDataReader to DTO with nullable field problem i integrate the unit test code which attached to this issue and i fixed it. I only add small if condition at the DataReaderMapper.cs


Applied Dec 31, 2009: Applied in R150

3567

Download

2479
by PlasticLizard
Feb 15, 2009
9:56 PM

Applied

Support for AutoMapping classes or DTO's that use public fields, instead of properties. If you are doing RESTful WCF, you will find that the XML generated from contracts/DTO's with auto-properties is a nasty mess, whereas public fields render to XML like they were lovingly hand coded. This patch includes a small set of changes (w/tests added to MemberResolution.cs scenario) that add a required layer of abstraction between AutoMapper and .NET reflection to allow fields and properties to be treating as equals.


Applied Feb 16, 2009: Looks good, I replaced the TypeMember concept with yours. Definitely simplified things.

Download

View All
  • 1-8 of 8 Patches
    • Previous
    • 1
    • Next
    • Showing
    • All
    • Patches