Updates to support .NET Standard and multi-targeting

[clairernovotny]

This is the latest branch of the PCL version, updated to support:

• net6.0
• net4
• netstandard2.0

That provides the widest range of functionality to supported platforms, including Xamarin and .NET Core. The netstandard2.0 version has the exact same surface area as the desktop net4 version.

Fixes #41

[jstedfast]

👍

[jstedfast]

@onovotny now that you are targeting .NETStandard 1.x, it should be possible to re-enable the DotNetUtilities class, right? Specifically, it'd be awesome to re-expose the methods that convert back and forth between BC and System.Security X509Certificates.

If I send you a PR, where should that go?

I want to completely switch to using Portable.BouncyCastle packages instead of maintaining my own iOS and Android project files for BouncyCastle and the only thing I'm missing is those conversion methods.

[jstedfast]

Looks like I actually only need 2 methods: GetKeyPair and FromX509Certificate.

[clairernovotny]

a PR should go to the netstandard branch of my fork

[jstedfast]

Looks like it's not possible even in netstandard1.3. I think I may just have to copy the DotNetUtilities class into MimeKit for use with Xamarin-specific targets if I want to expose the API's that allow users to pass in System.Security.Cryptography.X509Certificates.

The RSA and DSA classes needed for GetKeyPair don't exist in netstandard1.3.

No worries. I was hoping I wouldn't need to do that, but alas...

[clairernovotny]

@jstedfast what netstandard version are they in? I personally have no objections to including a higher version if there's a need. Multi-targeting is easy :)

[jstedfast]

I'm actually also targeting netstandard1.3 for MimeKit and MailKit. I just also have Xamarin-specific targets.

I just realized, however, that Mono's X509Certificate2 implementation doesn't include the PrivateKey anyway, so GetKeyPair is useless on the Xamarin platforms and the 1 case where all I need is the certificate, DotNetUtilities.FromX509Certificate() is just 1 line of code, so doing that "manually" inside MimeKit is not an issue.

[jstedfast]

I appreciate the offer, though!

[clairernovotny]

@jstedfast it's not hard to also target netstandard1.5/1.6 if that helps? better than Xamarin specific targets.

[martinstoeckli]

Did you ever think about creating a shared project? Shared projects are supported since Visual Studio 2013 Update 2, and as long as they do not have dependencies, they are a godsend for cross platform development.
No problems with dotnet versions/targets anymore, no problems with assembly versions or with loading libraries, just compiling and be done. Btw thanks for your efforts, they are really appreciated.

[clairernovotny]

@martinstoeckli I am familiar with shared projects, but what benefits would you see in this case over simply multi-targeting? One benefit I see with multi-targeting and the SDK-style projects are that all of the files can stay as-is, making it much easier to maintain.

[martinstoeckli]

There are so many variations of targets (dotnet version, OS platform, 32-64 bit, .Net core, ...) that I often get into the situation, that external libraries are mutually exclusive and I cannot use them. A shared project, as long as it doesn't have any problematic dependencies, is compiled to the same target as the app itself and therefore is always compatible. The multi-target libraries have to be maintained for every future target, a shared library is pure code. Of course this is a bit simplified and I must admit that I didn't have any problems with bc-csharp library so far. Thanks again.

[penartur]

@martinstoeckli ,

There are so many variations of targets (dotnet version, OS platform, 32-64 bit, .Net core, ...) that I often get into the situation, that external libraries are mutually exclusive and I cannot use them.

Targeting .NET Standard 1.0 immediately gives support of .NET Core, .NET Framework 4.5+, Mono 4.6+ and a lot of other platforms. Building for "AnyCPU" will make library compatible with x86, x64, ARM etc.

Library multi-targeting .NET Standard 1.0 and .NET Framework 1.1, built for AnyCPU, won't be mutually exclusive with anything else, until you have some unusual use case (e.g. your application needs to work with Xamarin.Mac 2.0).

[clairernovotny]

@jstedfast circling back on this, I just added a netstandard2.0 version that has the same surface area as the existing net4 version. Should have everything you need in it.

[jstedfast]

@onovotny awesome! (sorry, just saw your comment now)

[mdsitton]

Any reason this hasn't been merged after 6 years when this PR its still being maintained @peterdettman

[mdsitton]

Just as a follow on here this should be the # 1 priority of the library IMO if you check nuget a vast majoirty of users of the library are using other non-offical distributions of the library mainly targeted towards newer version of .net such as .net core or anything that supports .net standard:
https://www.nuget.org/packages?q=BouncyCastle

If people aren't using this library then donations and support will dwindle over time for the C# version risking the existence of the library. Moving to modernizing will increase the users and potentially donations if it can be widely advertised, maybe even have a specific donation tracker towards funding the modernization effort!

I've left a comment on #50 about further effort that should go into future work where i go over the current minimum supported .net framework versions which shows that .net standard 2.0 should be the minimum development target for this library. I would argue that supporting older .net framework versions and continuing to maintain support for these versions is itself promoting potentially outdated and vulnerable OS's and .net framework versions as these older framework version updates are tied with end of life os's

So because of that i think this PR should be redone with this in mind. and then in the future a BC 2.0 release should be done which drops support for older .net releases. Would be a great time to also do a lot of modernization work to move to generic collections, or Span/Memory based apis potentially. Since it would be a good opportunity for doing an API compatibility break. (though i don't know what BC's policy is on such api deprecation and whatnot.) Older versions can still be maintained in branches for critical bugfixes and security fixes.

[clairernovotny]

I'll add that AFAIK, the BouncyCastle nuget package isn't owned/maintained by anyone at BC itself and should not be considered trusted.

My fork is the apparent de-facto package and the CI pipeline is setup and public. The code is signed and published via pipelines, with all reproducible build checks in place, so it's also the most traceable/auditable version with a clear provenance.

I'm more than happy to continue maintaining/publishing that package as needed, and if the BC team makes a formal request to NuGet, we can get ownership of the "main" BouncyCastle package transferred over as well.

[mdsitton]

Yeah that's fair, though one thing that's important to me about this issue regardless of who's publishing it, is that the longer this isn't merged the longer it will be before library modernization can be done due to the library targeting .net 1.1 still (as far as i can tell)

[Xyncgas]

When will we get .NET 6 support utilizing Span and ref struct

[mdsitton]

When will we get .NET 6 support utilizing Span and ref struct

Looks like now judging by the commits happening in the repo currently!

[dghgit]

Yes, we're just waiting on a signing certificate so we can do a proper job on the packaging.

[peterdettman]

Here it is: https://www.nuget.org/packages/BouncyCastle.Cryptography.

This release is dedicated to @clairernovotny for keeping the project alive these past few years with Portable.BouncyCastle. Although we didn't merge this PR, it was used as the point of departure and to help us figure out the new project formats and tooling. Thanks for all your work, Claire.