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.

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