Automapper: Upgrade to 8.1.0 to 8.1.1 causes exception on previously functioning code

[CodingGorilla]

Source/destination types

// source type
public interface IResponseCollection<out T>
{
 IEnumerable<T> Members { get; }
}

// destination type
public class RepresentationCollection<out T>
{
  public IEnumerable<T> Members { get; set; }
}

Mapping configuration

Mapping configuration is automatically generated.

Version: x.y.z

AutoMapper Version: 8.1.1
AutoMapper.Extensions.Microsoft.DependencyInjection Version: 6.1.1

Expected behavior

When I revert the packages to 8.1.0 and 6.1.0 AutoMapper maps instances of these classes as expected.

Actual behavior

With the newer versions, I get the following exception:

AutoMapper.AutoMapperMappingException: Missing type map configuration or unsupported mapping.

 Mapping types:
 IResponseCollection`1 -> RepresentationCollection`1
 LaMotte.Platform.IResponseCollection`1[[LaMotte.BusinessLogic.ApiUser, LaMotte.BusinessLogic, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null]] -> LaMotte.Platform.WebApi.RepresentationCollection`1[[LaMotte.Api.Representations.UserRepresentation, LaMotte.Api, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null]]
    at RepresentationCollection<UserRepresentation> lambda_method(Closure, IResponseCollection<ApiUser>, RepresentationCollection<UserRepresentation>, ResolutionContext)
    at TDestination AutoMapper.Mapper.AutoMapper.IMapper.Map<TSource, TDestination>(TSource source)
    at object LaMotte.Platform.WebApi.OperationsControllerBase<TEntity, TRepresentation>.DetermineResponsePayload(object value)
    at OkObjectResult LaMotte.Platform.WebApi.OperationsControllerBase<TEntity, TRepresentation>.Ok(object value)
    at IActionResult LaMotte.Platform.WebApi.OperationsControllerBase.HandleApiOperationResult<T>(in ApiOperationResult<T> result, string createdLocation)
    at async Task<IActionResult> LaMotte.Api.Controllers.UsersController.GetUsersForMyOwner() in d:/a/1/s/src/LaMotte.Api/Controllers/UsersController.cs:line 67
    at async ValueTask<IActionResult> Microsoft.AspNetCore.Mvc.Internal.ActionMethodExecutor+TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, object controller, object[] arguments)
    at TResult System.Threading.Tasks.ValueTask<TResult>.get_Result()
    at async Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeActionMethodAsync()
    at async Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeNextActionFilterAsync()
    at void Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Rethrow(ActionExecutedContext context)
    at Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted)
    at async Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
    at async Task Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
    at async Task Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
    at async Task Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
    at async Task Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.Invoke(HttpContext httpContext)
    at async Task LaMotte.Platform.WebApi.LamotteAuthenticationMiddleware.Invoke(HttpContext context)
    at async Task Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)
    at async Task Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.Invoke(HttpContext context)

Adding an explicit CreateMap(typeof(IResponseCollection<>), typeof(RepresentationCollection<>)); solves the problem, however I wouldn't have expected to need this sort of a code change for a minor update. So I'm not sure if this change was intentional, nor what other things might be broken due to this change that I haven't discovered yet.

[lbargaoanu]

You've already found what to do about it. Dynamic mapping will be removed.

[CodingGorilla]

@lbargaoanu Ok, so should I expect future bug fix releases to break my code without warning?

[lbargaoanu]

The setting is there, just the default changed. What are we supposed to do, release a major version, change the default, another major version, remove the setting? That seems like a waste of everybody's time.

[snekbaev]

@lbargaoanu I believe I'm not the only one who actually relies on semantic versioning. I was planning to upgrade 8.1.0 to 8.1.1, publish to test and call it a day. When tests went up in smoke the first thing I thought there's a bug in a newer version of Automapper. The error message, then searching through the closed issues and finding out that behaviour has changed - I realised it was a breaking change. Talking about wasting time. Doubt many would care if it's major version 9 or 25, but definitely would appreciate some heads-up about potential problems, otherwise what's the point of using semver.

[lbargaoanu]

I think it only takes a minute to find out what changed and how to get the old behavior. There is actually an open issue (and pinned) about this specific change, but that's kind of besides the point, as that's what release notes are for. Anyway, if @jbogard sees it your way, he'll upgrade the version.

[snekbaev]

It may take one minute when one is aware of what's going on and what to look for. The failing code was written about a year ago, uses numerous other packages and had several Nuget updates since. In general, I don't read release notes for patch versions unless I'm expecting a certain fix. Occasionally I do read description for minor versions for important libraries, like ORM, but in either case I expect backwards compatibility.
I checked the three open issues, it didn't feel like it was related. Searching for "automapper 8.1.0 to 8.1.1 Missing type map configuration or unsupported mapping" yields this issue. The simple existence of this thread indicates I wasn't the only one confused.

[TheWix]

@lbargaoanu This change bit me also. Does this project not use semantic versioning? I would not expect, regardless of the ease of the upgrade, a bug fix to include breaking changes. There is a reason people accept minor releases automatically, because they don't expect breaking changes.

If you are using semantic versioning then yes, you bump the major version when there is a breaking change. That's the entire point.

[jbogard]

The entire feature is going away in the next major version, so folks are
going to get bit at some point...

@lbargaoanu I think we may want to revert the change in the default, that
was a behavior change.

On Tue, Jun 11, 2019 at 2:48 PM TheWix [e-mail] wrote:

@lbargaoanu https://github.com/lbargaoanu This change bit me also. Does
this project not use semantic versioning? I would not expect, regardless of
the ease of the upgrade, a bug fix to include breaking changes. There is a
reason people accept minor releases automatically, because they don't
expect breaking changes.

If you are using semantic versioning then yes, you bump the major version
when there is a breaking change. That's the entire point.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/3112?email_source=notifications&email_token=AAAZQMRYQRJZYYA5AHUU6TDPZ76SFA5CNFSM4HUJTEC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXOJRZI#issuecomment-500996325,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMWLBU5JBUAMOAIZHSDPZ76SFANCNFSM4HUJTECQ
.

[snekbaev]

@jbogard major version for things like that, yes, please!

P.S.: thank you and other contributors for all the hard work!

[lbargaoanu]

@jbogard I can make a PR to remove it altogether and be done with it. Because just deprecating it and keeping the default true, nobody will care :)

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.