Assembly does not have a strong name.

[rstutton]

Using the latest nuget package for my .net standard 2.0 library project, the build reports this: "Referenced assembly 'BouncyCastle.Crypto, Version=1.8.6.0, Culture=neutral, PublicKeyToken=null' does not have a strong name."

Checking the cached assemblies verifies this: C:\Users\robert.nuget\packages\bouncycastle.netcore\1.8.6\lib\netstandard2.0>sn -v BouncyCastle.Crypto.dll

Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 Copyright (c) Microsoft Corporation. All rights reserved.

BouncyCastle.Crypto.dll does not represent a strongly named assembly

[jstedfast]

bouncycastle.netcore is not maintained by the BouncyCastle authors.

I would recommend using Portable.BouncyCastle instead (another fork, but I'm pretty sure is strong named).

[clairernovotny]

The Portable.BouncyCastle library is strong named.

[queequac]

I got also tricked by using BouncyCastle.NetCore. Portable.BouncyCastle has most downloads for BouncyCastle on nuget, but it is still at version 1.9

I ended up with the official BouncyCastle.Cryptography being provided by LegionOfTheBouncyCastle. I was assuming this is the only official distribution among all the mirrors and alternatives...?

While it is strongly typed and holds the version number (which is genrated during build as I learned in https://github.com/bcgit/bc-csharp/issues/483, but the netcore mirror seems to omit this step), it adds more than 6MB to my release compared to the NetCore one. Could not really find out what is in there ... looks like static resources I obviously do not need in the netcore deployment.

[queequac]

One afterthought @peterdettman might be able to answer: Is this issue really still open? I was considering the latest builds to be strongly named.

Second, he might be able to judge what's the diff between BouncyCastle.NetCore and BouncyCastle.Cryptography that makes it 6MB fatter even though it calls itself a "mirror".