bc-csharp
bc-csharp copied to clipboard
bcgit
Updates to support .NET Standard and multi-targeting
This is the latest branch of the PCL version, updated to support:
net6.0net4netstandard2.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
@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.
Looks like I actually only need 2 methods: GetKeyPair and FromX509Certificate.
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...
@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 :)
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 it's not hard to also target netstandard1.5/1.6 if that helps? better than Xamarin specific targets.
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.
@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.
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.
@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).
@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.
Thanks for your efforts, can you please not delete BouncyCastle.csproj? Some of us still need .Net Framework 2.0 support!
All target frameworks can be reached from the current project format.
What project is only targeting 2.0 and is using the latest libraries? Projects that old are typically locked down and don't randomly update dependencies.
- Are you saying that I can still build a .Net Framework 2.0 compatible assembly with your proposed project format? could you please verify that?
- Why are there two 'crypto.csproj' in your fork? (crypto/crypto.csproj and crypto/src/crypto.csproj)
- There are many reasons to target the .Net Framework 2.0 on new projects, I'm not saying we should always cling to old versions at all cost, and I'm all for dropping .Net 1.1 support and using generics to improve the library and APIs, but if we could have .Net Framework 2.0 support at the cost of an additional project file it seems well worth it to me.
Yes, just add net20 to the TargetFrameworks list.
NET 2.0 is 12 years old. I really don't see why current libraries need to continue targeting it.
What reason is there to target 2.0 on a new project, I really can't think of any.
The other csproj is there to minimize merge conflicts for now.
Microsoft doesn't support anything older than, I think, .NET 4.6.1 at this point. Realistically, it probably doesn't make any sense to target anything older than 4.5. Every modern Windows system dating back to Vista SP2 supports .NET 4.5 so there's no reason not to.
Windows XP was the last OS that didn't support .NET 4.5 and even that supported .NET 4.0 and was end-of-lifed years ago.
Technically, net 4.5 and 4.5.1 aren't supported either. 4.5.2 is the lowest 4.x version getting patches.
3.5 SP1 is still getting patches too as it's a Windows component. I still would not use it for any new project :)
-
If you need an additional 'crypto.csproj' then please name it appropriately and put it where it belong (not in the 'src' directory)
-
While reviewing some of the 50 commits you pulled, I have noticed many changes to indentation (tabs become spaces or vice versa), while currently (and unfortunately) there is no consistency in the BC source code, IMO these changes should not be part of the current PR. also, I'm assuming you're going to rebase those 50 commits eventually.
-
We seem to be having the wrong discussion here, support for .NET Standard and support for .Net Framework 2.0 / 3.0 / 3.5 are not mutually exclusive.
-
I tried to open the new project file but it seems that VS2017 is required, can you keep a legacy project file to prevent us from the need to upgrade? (which for some of us has costs involved)
Again, I really appreciate the amount of work you've done here, and I'm all for .NET Standard, let's try to figure out a way to prevent this from being a breaking change, let me know if I can help in any way.
If you need an additional 'crypto.csproj' then please name it appropriately and put it where it belong (not in the 'src' directory)
This is following the recommended .NET project system. src contains the actual source files and test contains the test files. Each should have a project in them as the project files have default globs that include all files underneath. Having one above src means that src and test are in the same project, which is not the case.
While reviewing some of the 50 commits you pulled, I have noticed many changes to indentation (tabs become spaces or vice versa), while currently (and unfortunately) there is no consistency in the BC source code, IMO these changes should not be part of the current PR. also, I'm assuming you're going to rebase those 50 commits eventually.
I was hoping to avoid rebasing as this branch has lived too long. If a final rebase is necessary, then I'll do it just before it's merged. That still won't change the tabs/spaces issues. The only real way to address that is with an .editorconfig setting. BTW, VS 2017 includes support for that built-in.
We seem to be having the wrong discussion here, support for .NET Standard and support for .Net Framework 2.0 / 3.0 / 3.5 are not mutually exclusive.
Fair. I personally don't see the need in continuing it, but it's not hard to add an additional target for it.
I tried to open the new project file but it seems that VS2017 is required, can you keep a legacy project file to prevent us from the need to upgrade? (which for some of us has costs involved)
VS 2017 is fully required due to the significant enhancements in the build system. It is not possible to keep an older version. VS 2017 Community edition is free for OSS use and can be installed alongside any other VS edition. Note that VS 2017 isn't required to use the resulting package or binary, just for people building the project from source.
Furthermore, if the legacy projects are dropped (.NET 4, Portable-) and .NET 4.6 being the minimum, then dotnet can build it on any platform. Currently, MSBuild.exe is required due to the older platforms being targeting.
@peterdettman, @onovotny: is there any eta when this package is available as (beta) nuget? Thanks
It's already available here: https://www.nuget.org/packages/Portable.BouncyCastle/
It's already available here: https://www.nuget.org/packages/Portable.BouncyCastle/
Thank you. I was expecting to see the .netstandard support on the official package https://www.nuget.org/packages/BouncyCastle/ which states:
This is the final feature release with support for legacy .NET platforms. From 1.9.0 we will be targeting more modern .NET frameworks (see https://github.com/bcgit/bc-csharp/pull/68) and updating our build and packaging systems. The 1.8.x series will continue to receive bug fixes, but limited new functionality.
Therefor I was on the lookout for the version 1.9.0
Thank you for clarification. I'm quite disappointed about the communication from the official bc-team :(
