Automapper dependency makes SDK incompatible with Umbraco CMS

[Rarefied100]

Hi,

I have been working on an ecommerce website that uses Umbraco, and was struggling for a long time to figure out why I could never connect to the gateway (always received S9992 errors).

I identified thanks to issue #20 that the change to enforce TLS1.2 was the cause for this issue, as I was forced to use v1.4, because Umbraco's core binaries are signed to use AutoMapper v3.3.1.

As a result, I cannot install the new 1.5.x versions that include the TLS1.2 fix that would allow me to properly connect to eWAY.

Given that as far as I can tell there is no reason why you need to have AutoMapper v4.1.1, (aside from the previous requests to upgrade it) would it be possible to change the dependency to range from >=3.3.1 && <=4.1.1?

This would solve this compatibility issue completely.

Thanks for your time,
Steve

[incarnate]

Hi Steve,

Thanks for sharing the issues you've had with the SDK. AutoMapper's lack of backward compatibility has been a bit of a problem in the past, so we tend to declare dependencies tightly.

I've built a package with more permissive dependencies as you described and attached it below - would you be able to test that out to see if it works for you? Just rename the .zip to .nupkg. If that works fine we can do a release.

Thanks,
John

eWAY.Rapid.1.5.4-beta.zip

[Rarefied100]

Thanks for getting back so quickly John!

I have already had a fair amount of experience with AutoMapper's versioning frustrations, I can appreciate your desire to keep it strict. With that said, your beta package is working perfectly in my solution!

The only thing that I had to do was update my assembly binding redirects as it didn't automatically update it to deal with the higher version.
eg.

<dependentAssembly>
    <assemblyIdentity name="AutoMapper" publicKeyToken="be96cd2c38ef1005" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="3.3.1.0" />
</dependentAssembly>

I had to do it for both AutoMapper and Newtonsoft.Json.
I'm not sure if that is really a big issue though, it may just be because of the way that i installed it. I'm just thinking it may be confusing for someone installing for the first time if it starts throwing those kinds of errors out of the box.

It doesn't bother me in any case. I will use the beta version until 1.5.4 is released officially :)

Thanks!
Steve

[Slipoch]

Great work John,
I have tested and the package you supplied seems to work great.
It still worries me that a package involving payments (or any release package really) is using Automapper at all, as good OO programming practice and data security would suggest making inbuilt functions for each object to do their own conversions internally.

[cj1x]

Our company is also having dependency issues with AutoMapper. Seems like you should remove the dependency entirely.

[rollsch]

A year later and no response from eway.

[Slipoch]

Well they did have the alpha library linked above, but yes and these guys are better than most payment providers. The payment gateway industry is a joke, I've just been dealing with westpac's payway and it is a bloody shambles.

[thaoula]

Hi @incarnate,

One of our clients using the old 1.2.0 version of the library which broke last year.

I was hoping to use the above version and using an Assembly redirect however it seems that you guys changed the public key from 770aab8b0d10c257 -> 3ab6d5d95167133b

Anyway of getting an assembly signed with the old key?

The Automapper dependency makes upgrading very difficult because of an old umbraco version with a dependency on 3.3

Regards,
Tarek

[rollsch]

You can modify the signature yourself using dnspy. There is an example of how to do so on the dnspy github.

[thaoula]

Its a cryptographic signature so the changing the strong name this way means the assembly wont validate and I cannot disable strong name verification on Azure.

I hope @incarnate can provide me with an updated version of eWay can remove AutoMapper dependency (or ilmerge it into their assembly :) )

[rollsch]

You can delete the strong name signing as well in dnspy.

…

On 22 Feb 2018 11:41 AM, "Tarek Haoula" ***@***.***> wrote: Its a cryptographic signature so the changing the strong name this way means the assembly wont validate and I cannot disable strong name verification on Azure. I hope @incarnate <https://github.com/incarnate> can provide me with an updated version of eWay can remove AutoMapper dependency (or ilmerge it into their assembly :) ) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDuMqM5rF27qe_Et0dMUVPEou0uOBZ0ks5tXL7IgaJpZM4NvkAg> .

[incarnate]

Hi all,
I'm out of the office until next week, but I'll see what I can do about the key used when I get back next week.

Removing Automapper is certainly my preferred solution, but it isn't something we are able to get onto at the moment.

[Slipoch]

Initially (before my comments above) I did download the automapper project and changed the namespace of automapper to automapper331 or whatever I used in the other part of my project. This seemed to work.

[thaoula]

Hi @incarnate,

Just wondering if you have had a chance to look at this yet?

Regards,
Tarek

[incarnate]

@thaoula sorry for the delay on this, it took a bit longer to piece together the old build.

I've attached a package of version 1.2.0 which should be signed with our usual key. You'll just need to rename it from .zip to .nupkg.

Let me know if this doesn't work or you need something tweaked.

eWAY.Rapid.1.2.0.zip

[thaoula]

Hi @incarnate,

Thanks for the update. Unfortunately it did not work.

The current version of assembly we use is the following -
eWAY.Rapid, Version=1.2.0.0, Culture=neutral, PublicKeyToken=770aab8b0d10c257

The one you attached has a different public key token
eWAY.Rapid, Version=1.2.0.0, Culture=neutral, PublicKeyToken=3ab6d5d95167133b

I get a manifest error because the PublicKeyToken is different.

Regards,
Tarek

eWAY.Rapid.zip

[rollsch]

Just edit the assembly with dnspy. Takes 5 minutes.

[thaoula]

How do you edit the assembly. If you change the assembly details you still get an error. I have tried before as it was suggested previously Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Roland Harrison <[email protected]> Sent: Thursday, April 5, 2018 1:46:35 PM To: eWAYPayment/eway-rapid-net Cc: Tarek Haoula; Mention Subject: Re: [eWAYPayment/eway-rapid-net] Automapper dependency makes SDK incompatible with Umbraco CMS (#23) Just edit the assembly with dnspy. Takes 5 minutes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#23 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAVTzbpO5qinNuAfc-770zqYfmV1VP50ks5tlb3KgaJpZM4NvkAg>.

[stevomccormack]

I complained about AutoMapper many ions ago (like 3 years) when on phone to support. And peeps are still having issues today. The solutions suggested by eWAY are harder than removing AutoMapper altogether. Sad! Why was Stripe so successful? Because they understood developers (which became sales people and integrators). So sad eWAY still don’t get this.

[rollsch]

You can edit the expected public key token in your assembly that is referencing automated. That way there will be no error. Load up the assembly that is having the issue in dnspy and edit that.

[Slipoch]

WTF do people use automapper for!? A Jave library (Slow and shite) for translating one object to another. Hell you can do that easily with reflections in C# and you don't have to deal with the lag, the security issues or any other problems raised by using automapper.

All the 'solutions' on here are not solutions, they are workarounds.

Seriously guys, fix your code. Reflection is easy and if you cannot do it in less time than it takes to implement automapper, then you are doing it wrong.

[davidkeaveny]

Welcome to 2020, and AutoMapper is still an issue - I'm using the 1.6.1 version of the SDK, and it has a hard dependency on AutoMapper 6.2.2. The rest of my application is using 8.1.1; even with an assembly binding redirect, I'm getting the following error:

The type initializer for 'eWAY.Rapid.Internals.Services.MappingService' threw an exception.

Surely it must be time to fix this - either by getting rid of the dependency altogether, or by at least allowing us to override it?

[rollsch]

They have been experiencing Australia wide outages (2 in the last 6 months). I think this along with the complete lack of developer input here is indicative that they will probably never update this library. Someone else has forked it I believe, you could try that.

[egorpavlikhin]

Someone made a fork with update Automapper and .netstandard support https://github.com/hannan-gc/eway-rapid-net

[konarkdeshpande]

@egorpavlikhin, @rolandh Can i use above mentioned fork for our commercial use with upgrade it to AutoMapper latest version 9.0.0.0