search

AutoMapper / AutoMapper.Extensions.Microsoft.DependencyInjection

MIT License
258 stars 79 forks source link

Version 8.1.0 pulls in AutoMapper 10.1.0 #153

Closed mycroes closed 3 years ago

mycroes commented 3 years ago

Version 8.1.0 depends on AutoMapper 10.1.0, which had some issues which were fixed in 10.1.1 and the package has been unlisted from NuGet. However, adding a dependency on AutoMapper.Extensions.Microsoft.DependencyInjection without depending on AutoMapper will still pull in 10.1.0. I think it would be best to also release ...DependencyInjection 8.1.1 with a dependency on AutoMapper 10.1.1 to avoid this.

lbargaoanu commented 3 years ago

Meanwhile, you can use the MyGet build https://myget.org/feed/automapperdev/package/nuget/AutoMapper.Extensions.Microsoft.DependencyInjection.

jbogard commented 3 years ago

That's an easy fix, just pushed an 8.1.1 release.

lbargaoanu commented 3 years ago

@mycroes Check https://github.com/AutoMapper/AutoMapper/issues/3521. EF Core support is mostly accidental.

mycroes commented 3 years ago

Thanks @jbogard, I knew it was easy, didn't have time to PR it this afternoon so I'm very happy you made the change.

@lbargaoanu I'd rather not use any packages from other sources than the official NuGet repository and our company repo (private infra only). It creates an additional maintenance burden if I (and colleagues) would have to keep track of why some package is used from an additional source (apart from actually managing additional sources, both in development environments and CI). Adding an additional dependency on AutoMapper itself would also have worked, but still this feels like the best solution to me.

We've actually spent about an hour with 3 people trying to figure out why some of our queries suddenly broke while most other queries were still working fine, I'd like to avoid the same situation for anyone else that has only taken a dependency on AutoMapper.Extensions.Microsoft.DependencyInjection. This hit us out of nowhere so when we figured it was the AutoMapper update we reverted ...DependencyInjection back to the previous release we were using because we also didn't have the time to check for an actual solution either (an automated cheese factory without control is a hassle).

Also, I was quite amazed that NuGet pulls in the exact version of a dependency (AutoMapper in this case) even if it's unlisted. I know there are or have been dependency resolution strategies for NuGet that might affect this, but I wouldn't have assumed it would behave like this by default.

Either way, thanks for responding and fixing!

Regards, Michael

github-actions[bot] commented 3 years ago

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