BouncyCastle v1.7.0 dependency version conflict error

[Sojaner]

I have an asp.net core 1.1.0-preview1 running on .net v4.6.2 and I use Google.Apis.Analytics.v3 v1.19.0.642 and Google.Apis.AnalyticsReporting.v4 v1.19.0.649 therefore my project indirectly uses Google.Apis.Auth v1.19.0 which has BouncyCastle version >= 1.7.0 as a dependency.

The project was working fine until I installed MailKit v1.10.0 which is dependent on BouncyCastle version >= 1.8.1 which forces the project to use BouncyCastle v1.8.1.

According to NuGet package of Google.Apis.Auth v1.19.0 the dependency is to BouncyCastle version >= 1.7.0 therefore v1.8.1 should be working fine.

However, since the install of MailKit v1.10.0 I keep receiving the following error...

Could not load file or assembly 'BouncyCastle.Crypto, Version=1.7.4137.9688, Culture=neutral, PublicKeyToken=a4292a325f69b123' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

...when calling GoogleCredential.FromStream(stream).

The strange part is that when checking the assembly file Google.Apis.Auth v1.19.0, it doesn't show any explicit reference to BouncyCastle.Crypto v1.7.4137.9688.

My current workaround is to explicitly reference BouncyCastle.Crypto v1.7.0 in my project and regarding that I am not using SSL protocols with MailKit, that works fine...

...however:

1. I have reference in my project that raises many warnings while running and compiling.
2. as soon as I activate the SSL there will probably be problems with dependency to BouncyCastle v1.8.1.

Can someone take a look and find the problem please?

[chrisdunelm]

This is almost certainly due to the BouncyCastle public key token being changed between BouncyCastle version 1.7.0 and 1.8.1
Unfortunately this means they are seen as different libraries, rather than different versions of the same library.
See #453 on the google-cloud-dotnet repo for more details.
If this is the problem, then there's not really anything we can do :(

It's the Auth PlatformServices library that has a dependency on BouncyCastle. See the packages.config. This is packaged in the Google.Apis.Auth nuget package.

[Sojaner]

Thanks for the explanation @chrisdunelm that makes scene now.

My question now is why not to update BouncyCastle dependency to 1.8.1 in Auth PlatformServices?

As I can see version 1.7.0 is pretty old and in my opinion it's time to update any code which is dependent on this library to the newest ones.

[chrisdunelm]

@Sojaner: Yes, we'd like to update to BouncyCastle v1.8.1 and doing so is part of our plan for v2.0 of these libraries.
Although the v1.7.0 -> v1.8.1 is theoretically a minor version update, which we could therefore do within a minor version update of our libraries; the changing public key token problem will make this extremely disruptive for many users, so we're very reluctant to do so.

[Sojaner]

That's great to hear @chrisdunelm

Another temporary solution came to my mind is, we have the source for BouncyCastle 1.7.0 and the private key used for v1.8.1, do you think if it works to create an unofficial BouncyCastle 1.7.0 NuGet compiled with private key from v1.8.1 and have a version of Auth PlatformService referencing that library?

This way both the public key problem is solved and any chance for API incompatibility between v1.7.0 and v1.8.1 will be prevented.

[mstrange86]

@chrisdunelm I sent a possible fix which internalizes the BouncyCastle.Crypto.dll components using ILRepack and should drop the need for external libraries of any version. I can confirm this compiled DLL works fine with MimeKit pointing to BouncyCastle.Crypto 1.8.1

#878

[divad4686]

Our temporary solution for this was to install the 1.7 version of BouncyCastle in the Global Assembly Cache using the GAC util from visual studio console https://msdn.microsoft.com/en-us/library/ex0ss12c(v=vs.110).aspx

This way Mailkit looks for the DLL in the project, while google after not finding it (because the token difference) looks in the GAC.

[chrisdunelm]

Thanks for PR #878, but we're looking at completely removing the dependency on BouncyCastle.
We certainly want to do this for v2 of the libraries, and are considering doing it now for v1.x, to remove this problem.
I'll keep this issue updated with progress.