Update namingfrom AutoMapper to MagicMapper

where it obviously make sense. I still don't want to break API naming, to simplify life of people. Once it's done, I will provide compatibility package which should be addon to MagicMapper

Author: kant2002

docs/source/API-Changes.md

@@ -1,5 +1,5 @@
 # API Changes
 
-Starting with version 9.0, you can find out [what changed](https://raw.githubusercontent.com/AutoMapper/AutoMapper/master/src/AutoMapper/ApiCompatBaseline.txt) in the public API from the last major version release.
-From the [releases page](https://github.com/AutoMapper/AutoMapper/releases) you can reach the source code for that release and the version of ApiCompatBaseline.txt in that tree will tell you what changed.
+Starting with version 9.0, you can find out [what changed](https://raw.githubusercontent.com/NET-Sorcery/MagicMapper/master/src/AutoMapper/ApiCompatBaseline.txt) in the public API from the last major version release.
+From the [releases page](https://github.com/NET-Sorcery/MagicMapper/releases) you can reach the source code for that release and the version of ApiCompatBaseline.txt in that tree will tell you what changed.
 A major version release is compared with the previous major version release (so 9.0.0 with 8.0.0) and a minor version release with the current major version release (so 9.1.1 with 9.0.0).

docs/source/Before-and-after-map-actions.md

@@ -1,6 +1,6 @@
 # Before and After Map Action
 
-Occasionally, you might need to perform custom logic before or after a map occurs. These should be a rarity, as it's more obvious to do this work outside of AutoMapper. You can create global before/after map actions:
+Occasionally, you might need to perform custom logic before or after a map occurs. These should be a rarity, as it's more obvious to do this work outside of MagicMapper. You can create global before/after map actions:
 
 ```c#
 var configuration = new MapperConfiguration(cfg => {

docs/source/Conditional-mapping.md

@@ -1,6 +1,6 @@
 # Conditional Mapping
 
-AutoMapper allows you to add conditions to properties that must be met before that property will be mapped.
+MagicMapper allows you to add conditions to properties that must be met before that property will be mapped.
 
 This can be used in situations like the following where we are trying to map from an int to an unsigned int.
 ```c#

docs/source/Configuration-validation.md

@@ -1,8 +1,8 @@
 # Configuration Validation
 
-Hand-rolled mapping code, though tedious, has the advantage of being testable.  One of the inspirations behind AutoMapper was to eliminate not just the custom mapping code, but eliminate the need for manual testing.  Because the mapping from source to destination is convention-based, you will still need to test your configuration.
+Hand-rolled mapping code, though tedious, has the advantage of being testable.  One of the inspirations behind MagicMapper was to eliminate not just the custom mapping code, but eliminate the need for manual testing.  Because the mapping from source to destination is convention-based, you will still need to test your configuration.
 
-AutoMapper provides configuration testing in the form of the AssertConfigurationIsValid method.  Suppose we have slightly misconfigured our source and destination types:
+MagicMapper provides configuration testing in the form of the AssertConfigurationIsValid method.  Suppose we have slightly misconfigured our source and destination types:
 ```c#
 public class Source
 {
@@ -41,7 +41,7 @@ var configuration = new MapperConfiguration(cfg =>
 
 ## Selecting members to validate
 
-By default, AutoMapper uses the destination type to validate members. It assumes that all destination members need to be mapped. To modify this behavior, use the `CreateMap` overload to specify which member list to validate against:
+By default, MagicMapper uses the destination type to validate members. It assumes that all destination members need to be mapped. To modify this behavior, use the `CreateMap` overload to specify which member list to validate against:
 
 ```c#
 var configuration = new MapperConfiguration(cfg =>
@@ -55,4 +55,4 @@ To skip validation altogether for this map, use `MemberList.None`. That's the de
 
 ## Custom validations
 
-You can add custom validations through an extension point. See [here](https://github.com/AutoMapper/AutoMapper/blob/master/src/UnitTests/CustomValidations.cs).
+You can add custom validations through an extension point. See [here](https://github.com/NET-Sorcery/MagicMapper/blob/master/src/UnitTests/CustomValidations.cs).

docs/source/Configuration.md

@@ -85,7 +85,7 @@ var configuration = new MapperConfiguration(cfg =>
 );
 ```
 
-AutoMapper will scan the designated assemblies for classes inheriting from Profile and add them to the configuration.
+MagicMapper will scan the designated assemblies for classes inheriting from Profile and add them to the configuration.
 
 ## Naming Conventions
 
@@ -166,7 +166,7 @@ var configuration = new MapperConfiguration(cfg => {
 configuration.AssertConfigurationIsValid();
 ```
 
-By default AutoMapper recognizes the prefix "Get", if you need to clear the prefix:
+By default MagicMapper recognizes the prefix "Get", if you need to clear the prefix:
 
 ```c#
 var configuration = new MapperConfiguration(cfg => {
@@ -177,7 +177,7 @@ var configuration = new MapperConfiguration(cfg => {
 
 ## Global property/field filtering
 
-By default, AutoMapper tries to map every public property/field. You can filter out properties/fields with the property/field filters:
+By default, MagicMapper tries to map every public property/field. You can filter out properties/fields with the property/field filters:
 
 ```c#
 var configuration = new MapperConfiguration(cfg =>
@@ -193,7 +193,7 @@ var configuration = new MapperConfiguration(cfg =>
 
 ## Configuring visibility
 
-By default, AutoMapper only recognizes public members. It can map to private setters, but will skip internal/private methods and properties if the entire property is private/internal. To instruct AutoMapper to recognize members with other visibilities, override the default filters ShouldMapField and/or ShouldMapProperty :
+By default, MagicMapper only recognizes public members. It can map to private setters, but will skip internal/private methods and properties if the entire property is private/internal. To instruct MagicMapper to recognize members with other visibilities, override the default filters ShouldMapField and/or ShouldMapProperty :
 
 ```c#
 var configuration = new MapperConfiguration(cfg =>
@@ -208,7 +208,7 @@ Map configurations will now recognize internal/private members.
 
 ## Configuration compilation
 
-Because expression compilation can be a bit resource intensive, AutoMapper lazily compiles the type map plans on first map. However, this behavior is not always desirable, so you can tell AutoMapper to compile its mappings directly:
+Because expression compilation can be a bit resource intensive, MagicMapper lazily compiles the type map plans on first map. However, this behavior is not always desirable, so you can tell MagicMapper to compile its mappings directly:
 
 ```c#
 var configuration = new MapperConfiguration(cfg => {});

docs/source/Construction.md

@@ -1,6 +1,6 @@
 # Construction
 
-AutoMapper can map to destination constructors based on source members:
+MagicMapper can map to destination constructors based on source members:
 
 ```c#
 public class Source {

docs/source/Custom-type-converters.md

@@ -24,7 +24,7 @@ public class Destination
 }
 ```
 
-If we were to try and map these two types as-is, AutoMapper would throw an exception (at map time and configuration-checking time), as AutoMapper does not know about any mapping from string to int, DateTime or Type.  To create maps for these types, we must supply a custom type converter, and we have three ways of doing so:
+If we were to try and map these two types as-is, MagicMapper would throw an exception (at map time and configuration-checking time), as MagicMapper does not know about any mapping from string to int, DateTime or Type.  To create maps for these types, we must supply a custom type converter, and we have three ways of doing so:
 
 ```c#
 void ConvertUsing(Func<TSource, TDestination> mappingFunction);
@@ -41,7 +41,7 @@ public interface ITypeConverter<in TSource, TDestination>
 }
 ```
 
-And supply AutoMapper with either an instance of a custom type converter, or simply the type, which AutoMapper will instantiate at run time.  The mapping configuration for our above source/destination types then becomes:
+And supply MagicMapper with either an instance of a custom type converter, or simply the type, which MagicMapper will instantiate at run time.  The mapping configuration for our above source/destination types then becomes:
 
 ```c#
 [Test]

docs/source/Custom-value-resolvers.md

@@ -1,6 +1,6 @@
 # Custom Value Resolvers
 
-Although AutoMapper covers quite a few destination member mapping scenarios, there are the 1 to 5% of destination values that need a little help in resolving.  Many times, this custom value resolution logic is domain logic that can go straight on our domain.  However, if this logic pertains only to the mapping operation, it would clutter our source types with unnecessary behavior.  In these cases, AutoMapper allows for configuring custom value resolvers for destination members.  For example, we might want to have a calculated value just during mapping:
+Although MagicMapper covers quite a few destination member mapping scenarios, there are the 1 to 5% of destination values that need a little help in resolving.  Many times, this custom value resolution logic is domain logic that can go straight on our domain.  However, if this logic pertains only to the mapping operation, it would clutter our source types with unnecessary behavior.  In these cases, MagicMapper allows for configuring custom value resolvers for destination members.  For example, we might want to have a calculated value just during mapping:
 
 ```c#
 public class Source
@@ -36,13 +36,13 @@ public class CustomResolver : IValueResolver<Source, Destination, int>
 }
 ```
 
-Once we have our IValueResolver implementation, we'll need to tell AutoMapper to use this custom value resolver when resolving a specific destination member.  We have several options in telling AutoMapper a custom value resolver to use, including:
+Once we have our IValueResolver implementation, we'll need to tell MagicMapper to use this custom value resolver when resolving a specific destination member.  We have several options in telling MagicMapper a custom value resolver to use, including:
 
 * MapFrom\<TValueResolver\>
 * MapFrom(typeof(CustomValueResolver))
 * MapFrom(aValueResolverInstance)
 
-In the below example, we'll use the first option, telling AutoMapper the custom resolver type through generics:
+In the below example, we'll use the first option, telling MagicMapper the custom resolver type through generics:
 
 ```c#
 var configuration = new MapperConfiguration(cfg =>
@@ -75,9 +75,9 @@ public class MultBy2Resolver : IValueResolver<object, object, int> {
 
 ### Custom constructor methods
 
-Because we only supplied the type of the custom resolver to AutoMapper, the mapping engine will use reflection to create an instance of the value resolver.
+Because we only supplied the type of the custom resolver to MagicMapper, the mapping engine will use reflection to create an instance of the value resolver.
 
-If we don't want AutoMapper to use reflection to create the instance, we can supply it directly:
+If we don't want MagicMapper to use reflection to create the instance, we can supply it directly:
 
 ```c#
 var configuration = new MapperConfiguration(cfg => cfg.CreateMap<Source, Destination>()
@@ -86,15 +86,15 @@ var configuration = new MapperConfiguration(cfg => cfg.CreateMap<Source, Destina
 	));
 ```
 
-AutoMapper will use that specific object, helpful in scenarios where the resolver might have constructor arguments or need to be constructed by an IoC container.
+MagicMapper will use that specific object, helpful in scenarios where the resolver might have constructor arguments or need to be constructed by an IoC container.
 
 ### The resolved value is mapped to the destination property
 
 Note that the value you return from your resolver is not simply assigned to the destination property. Any map that applies will be used and the result of that mapping will be the final destination property value. Check [the execution plan](Understanding-your-mapping.html).
 
 ### Customizing the source value supplied to the resolver
 
-By default, AutoMapper passes the source object to the resolver. This limits the reusability of resolvers, since the resolver is coupled to the source type. If, however, we supply a common resolver across multiple types, we configure AutoMapper to redirect the source value supplied to the resolver, and also use a different resolver interface so that our resolver can get use of the source/destination members:
+By default, MagicMapper passes the source object to the resolver. This limits the reusability of resolvers, since the resolver is coupled to the source type. If, however, we supply a common resolver across multiple types, we configure MagicMapper to redirect the source value supplied to the resolver, and also use a different resolver interface so that our resolver can get use of the source/destination members:
 
 ```c#
 var configuration = new MapperConfiguration(cfg => {
@@ -131,11 +131,11 @@ Starting with version 13.0, you can use `context.State` instead, in a similar wa
 
 ### ForPath
 
-Similar to ForMember, from 6.1.0 there is ForPath. Check out [the tests](https://github.com/AutoMapper/AutoMapper/search?utf8=%E2%9C%93&q=ForPath&type=) for examples.
+Similar to ForMember, from 6.1.0 there is ForPath. Check out [the tests](https://github.com/NET-Sorcery/MagicMapper/search?utf8=%E2%9C%93&q=ForPath&type=) for examples.
 
 ### Resolvers and conditions
 
-For each property mapping, AutoMapper attempts to resolve the destination value **before** evaluating the condition. So it needs to be able to do that without throwing an exception even if the condition will prevent the resulting value from being used.
+For each property mapping, MagicMapper attempts to resolve the destination value **before** evaluating the condition. So it needs to be able to do that without throwing an exception even if the condition will prevent the resulting value from being used.
 
 As an example, here's sample output from [BuildExecutionPlan](Understanding-your-mapping.html) (displayed using [ReadableExpressions](https://marketplace.visualstudio.com/items?itemName=vs-publisher-1232914.ReadableExpressionsVisualizers)) for a single property:
 

docs/source/Dependency-injection.md

@@ -4,7 +4,7 @@
 
 ### ASP.NET Core
 
-There is a [NuGet package](https://www.nuget.org/packages/AutoMapper.Extensions.Microsoft.DependencyInjection/) to be used with the default injection mechanism described [here](https://github.com/AutoMapper/AutoMapper.Extensions.Microsoft.DependencyInjection) and used in [this project](https://github.com/jbogard/ContosoUniversityCore/blob/master/src/ContosoUniversityCore/Startup.cs).
+There is a [NuGet package](https://www.nuget.org/packages/AutoMapper.Extensions.Microsoft.DependencyInjection/) to be used with the default injection mechanism described [here](https://github.com/NET-Sorcery/MagicMapper.Extensions.Microsoft.DependencyInjection) and used in [this project](https://github.com/jbogard/ContosoUniversityCore/blob/master/src/ContosoUniversityCore/Startup.cs).
 
 Starting with version 13.0, `AddAutoMapper` is part of the core package and the DI package is discontinued.
 
@@ -16,7 +16,7 @@ or marker types:
 ```c#
 services.AddAutoMapper(typeof(ProfileTypeFromAssembly1), typeof(ProfileTypeFromAssembly2) /*, ...*/);
 ```
-Now you can inject AutoMapper at runtime into your services/controllers:
+Now you can inject MagicMapper at runtime into your services/controllers:
 ```c#
 public class EmployeesController {
 	private readonly IMapper _mapper;
@@ -32,11 +32,11 @@ There is a third-party [NuGet package](https://www.nuget.org/packages/AutoMapper
 
 Also, check [this blog](https://dotnetfalcon.com/autofac-support-for-automapper/).
 
-### [Other DI engines](https://github.com/AutoMapper/AutoMapper/wiki/DI-examples)
+### [Other DI engines](https://github.com/NET-Sorcery/MagicMapper/wiki/DI-examples)
 
 ## Low level API-s
 
-AutoMapper supports the ability to construct [Custom Value Resolvers](Custom-value-resolvers.html), [Custom Type Converters](Custom-type-converters.html), and [Value Converters](Value-converters.html) using static service location:
+MagicMapper supports the ability to construct [Custom Value Resolvers](Custom-value-resolvers.html), [Custom Type Converters](Custom-type-converters.html), and [Value Converters](Value-converters.html) using static service location:
 
 ```c#
 var configuration = new MapperConfiguration(cfg =>

docs/source/Dynamic-and-ExpandoObject-Mapping.md

@@ -1,6 +1,6 @@
 # Dynamic and ExpandoObject Mapping
 
-AutoMapper can map to/from dynamic objects without any explicit configuration:
+MagicMapper can map to/from dynamic objects without any explicit configuration:
 
 ```c#
 public class Foo {
@@ -23,7 +23,7 @@ foo2.Bar.ShouldEqual(5);
 foo2.Baz.ShouldEqual(6);
 ```
 
-Similarly you can map straight from `Dictionary<string, object>` to objects, AutoMapper will line up the keys with property names.
+Similarly you can map straight from `Dictionary<string, object>` to objects, MagicMapper will line up the keys with property names.
 For mapping to destination child objects, you can use the dot notation.
 ```c#
 var result = mapper.Map<Foo>(new Dictionary<string, object> { ["InnerFoo.Bar"] = 42 });