AutoMapper Source Code Rss Feed

Source code checked in, #76924

Project Collection Service Accounts — Mon, 01 Oct 2012 21:29:18 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #76923

Project Collection Service Accounts — Mon, 01 Oct 2012 21:23:54 GMT

Checked in by server upgrade

Patch Applied: #6763

jbogard — Wed, 03 Nov 2010 02:57:28 GMT

jbogard has applied patch #6763.

Comment:
Cause it works. Thanks!

Source code checked in, #58085

jbogard — Wed, 03 Nov 2010 02:56:31 GMT

Updated readme to point to GitHub as the source code (https://github.com/jbogard/AutoMapper)

Patch Uploaded: #6763

Valeriob — Tue, 14 Sep 2010 20:02:17 GMT

Valeriob has uploaded a patch.

Description:
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.

Source code checked in, #49966

_TFSSERVICE — Mon, 19 Jul 2010 20:19:27 GMT

Checked in by server upgrade

Patch Uploaded: #5328

mighty_man — Mon, 22 Feb 2010 13:37:12 GMT

mighty_man has uploaded a patch.

Description:
Logo original and overview/guide pdf, as zip.

Patch Uploaded: #5327

mighty_man — Mon, 22 Feb 2010 08:33:08 GMT

mighty_man has uploaded a patch.

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

Patch Applied: #5274

jbogard — Thu, 18 Feb 2010 18:11:11 GMT

jbogard has applied patch #5274.

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

Patch Uploaded: #5274

kfinley — Mon, 15 Feb 2010 19:12:28 GMT

kfinley has uploaded a patch.

Description:
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

Patch Applied: #4658

jbogard — Thu, 31 Dec 2009 21:43:57 GMT

jbogard has applied patch #4658.

Comment:
Applied in R150

Patch Uploaded: #4710

wes_mcclure — Tue, 22 Dec 2009 05:38:11 GMT

wes_mcclure has uploaded a patch.

Description:
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.

Patch Uploaded: #4658

enghamed — Mon, 14 Dec 2009 18:13:16 GMT

enghamed has uploaded a patch.

Description:
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

Patch Uploaded: #4201

SanderSaares2 — Thu, 22 Oct 2009 09:16:57 GMT

SanderSaares2 has uploaded a patch.

Description:
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!

Source code checked in, #20172

jbogard — Thu, 11 Jun 2009 12:39:38 GMT

Removing confusing zip file and adding readme pointing to the GoogleCode repo

Patch Applied: #2479

jbogard — Mon, 16 Feb 2009 16:12:09 GMT

jbogard has applied patch #2479.

Comment:
Looks good, I replaced the TypeMember concept with yours. Definitely simplified things.

Patch Uploaded: #2479

PlasticLizard — Sun, 15 Feb 2009 22:56:43 GMT

PlasticLIzard has uploaded a patch.

Description:
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.

Source code checked in, #4373

jbogard — Mon, 19 Jan 2009 04:28:59 GMT

CodePlex requires source code. Whatever.