PCL support

[bcgit]

PCL support

[dnauck]

Please take a look at my long outstanding patch ;)

http://www.bouncycastle.org/jira/browse/BMA-107

[clairernovotny]

@dnauck That works too...either way, it'd be good/useful to have something in the official source and NuGet.

[jstedfast]

hi @dnauck

I look a quick look over your patch and I think it'd be better if, instead of continuing the .NET 1.1 paradigm of using Stream.Close(), the code was fixed instead to use the .NET >= 2.0 paradigm of Stream.Dispose() and thus each stream subclass would override Dispose (bool disposing)

I've actually been working on my own patch for this based on my visual-studio-2010 branch (haven't committed my Close -> Dispose or other .NET 2.0-ification patches yet, though, as I'm waiting for v1.8 to be released to simplify my merging).

Stuff like this:

+#if PORTABLE
+            if (name.ToUpperInvariant().StartsWith("OID."))
+#else
             if (name.ToUpper(CultureInfo.InvariantCulture).StartsWith("OID."))
+#endif

could be greatly simplified in Bouncy Castle "2.0" (my understanding is that once Peter releases v1.8, he'll be starting on "2.0" which will drop .NET 1.1 support in favor of moving at least to .NET 2.0 - although, honestly, I am personally hoping for .NET 4.0).

By migrating the entire code base to be able to depend on at least .NET 2.0 features, so much of the code could be simplified to not even need a lot of fixes like above.

[clairernovotny]

BTW, I've redone my fork here: https://github.com/onovotny/BouncyCastle-PCL/tree/pcl It's now directly off the main repo so will merge in trivially.

[peterdettman]

I think I've now patched everything for PORTABLE except the Close/Dispose stuff, which as @jstedfast points out would be much easier to just address as part of 2.0+ migration. However, we can live with the PORTABLE-switched Close/Dispose, and with 1.8.0-RC.2 wrapped and on it's way to the printers, there is now a week or so (a little more if we really need it) before a stable release.

So (@onovotny ?), we'd like to get a PR against the current master (there's a release-1.8.0-RC.2 tag) that sorts out the remaining code issues (primarily Close/Dispose), preferably modifying very little code outside of PORTABLE blocks. Also, Visual Studio build files will be fine, no need to bother with NAnt (I'm hoping for VS files for the regular build also, see #22).

[clairernovotny]

@peterdettman have you seen what I've done in my PR? It is based off of the current master on this repo here, adding PCL and CoreCLR support. The biggest issue now is that I'm getting a compile-time error with CMSSignedDataGenerator line 140. I'm using the SILVERLIGHT constant for the PCL stuff as it is closer to what's available.

Error 17 Argument 1: cannot convert from 'System.IO.Stream' to 'Org.BouncyCastle.Crypto.ISigner' C:\Users\oren\Source\Git\BouncyCastle-PCL\crypto\src\cms\CMSSignedDataGenerator.cs 140 41 crypto.Net45

[peterdettman]

Ah, that line should probably just read:
Stream sigStr = calculator.Stream;

Sorry about that, I was holding off even checking the PORTABLE stuff until after RC.2.

[clairernovotny]

thought so based on the other usage. Is there a gitter/slack/somewhere we can sync on what I've done in the fork and why?

[peterdettman]

Yeah, that'd be cool, we'll figure out somewhere in the next few days; I'm afraid I'm too exhausted for plans at the moment.

[clairernovotny]

I still see a test failure:

Test Name: TestFunction
Test FullName: Org.BouncyCastle.Pkcs.Tests.EncryptedPrivateKeyInfoTest.TestFunction
Test Source: C:\Users\oren\Source\Git\BouncyCastle-PCL\crypto\test\src\pkcs\test\EncryptedPrivateKeyInfoTest.cs : line 87
Test Outcome: Failed
Test Duration: 0:00:00.028

Result StackTrace: at Org.BouncyCastle.Pkcs.Tests.EncryptedPrivateKeyInfoTest.TestFunction() in C:\Users\oren\Source\Git\BouncyCastle-PCL\crypto\test\src\pkcs\test\EncryptedPrivateKeyInfoTest.cs:line 89
Result Message:
Expected string length 33 but was 874. Strings differ at index 29.
Expected: "EncryptedPrivateKeyInfoTest: Okay"
But was: "EncryptedPrivateKeyInfoTest: Exception: System.ArgumentExcept..."
----------------------------------------^

[clairernovotny]

It's coming from EncryptedPrivateKeyInfo.GetInstance where the obj isn't any of the two items it's testing for so it hits the argument exception.

The full message is

Unknown object in factory: Org.BouncyCastle.Asn1.DerApplicationSpecific\r\nParameter name: obj"

[peterdettman]

I take it this is when running the PCL version, as I don't get any error there. It might be best to wait until the latest source is mirrored to github (look for release-1.8.0-RC.2 tag), and once I have a proper PCL build here, it'll be simple to resolve any test failures.

[clairernovotny]

Sure, just lmk. BTW, the test repros (fails) on my master-vs12 branch too, which is a .NET 2 project. I've been using a branch promotion pattern to keep my master equal to yours, have VS 2012+ project files in one branch that uses a recursive include of files (so I never have to update them). I left the old VS 1.1 project file alone as it was unmergable to the new format.

So the master-vs12 branch is virtually identical to master. The only difference is that my .NET 2 project defines the following: LIB;PCL;SILVERLIGHT.

Then, I have a PCL branch where I've updated the vs 2012 project files to be a PCL (and added a second CoreCLR/dotnet PCL project) and made minor tweaks to add || PCL in places where it needed to be.

I'm happy to discuss more when you're ready.

Github mirror should sync up shortly.

[clairernovotny]

All merged in. Check out the latest CI build:
https://ci.appveyor.com/project/onovotny/bouncycastle-pcl

This version actually generates 3 libraries, all PCLs:

1. A Profile 328 one that includes .NET 4 and SL5
2. A Profile 259 one that is .NET 4.5, WP8, Wpa81 and Win8
3. A "modern PCL" based on .NET Core that targets .NET 4.6, UWP and Core CLR

Of the three, item 1 could be possibly nixed as starting Jan 16, .NET 4, 4.5 and 4.5.1 lose all support, including security updates. No one should be on them. (.NET 3.5 SP1 and .NET 4.5.2 are fully supported).

Having 3 is useful because .NET Core brings back File-related operations

[peterdettman]

@onovotny The test failure was because a README.txt file was being pulled in as test data (in the old VS project file, not all the files are marked as embedded resources). Anyway, fixed with a simple filter.

[clairernovotny]

Okay, good to know. which file is it? I've been using a recursive include in my project files as it's the easiest way to mirror your repo. I'd suggest that once it's merged in that the files be put into a shared project that is then referenced by the multiple "head" projects.

[peterdettman]

BouncyCastle-PCL\crypto\test\data\keys\README.txt is the one triggering the problem. AFAICT it's the only case where something "extra" is included that actually causes a problem. Shared project should be OK, I'm concerned (just for 1.8) to leave the existing build intact though.

Is BouncyCastle-PCL currently for VS 2010? I get a ""Microsoft.Portable.CSharp.targets" was not found" for the crypto.dotnet project (VS 2015 CE).

[clairernovotny]

I totally agree that for 1.8, nothing should change...it's too close to release.

AFAIK, the Portable projects don't work on VS 2010 as the PCL stuff change quite a lot since then. Further, the .NET Core version requires VS 2015/MSBuild 14 to compile. I think that version is worth it as it adds back File* support as that's available in .NET Core. The .NET Core stuff will work on CoreCLR, UWP, etc.

[peterdettman]

So should a fresh clone of BouncyCastle-PCL.sln open cleanly in VS 2015 CE?

[clairernovotny]

The PCL branch should, yes. There's a CI build setup for it too that shows it cloning/building cleanly: https://ci.appveyor.com/project/onovotny/bouncycastle-pcl

[clairernovotny]

Excluding that readme.txt did the trick, clean build now with tests passing!

https://ci.appveyor.com/project/onovotny/bouncycastle-pcl/build/1.8.0-rc.4+194%20(Build%2051)

[peterdettman]

On a clean clone, on the plc branch, I open in VS 2015 CE and fail to load crypto.dotnet project with this error:

C:\Users\Peter\My Code\bc\git\BouncyCastle-PCL\crypto\crypto.dotnet.csproj : error : The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Portable\v5.0\Microsoft.Portable.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Users\Peter\My Code\bc\git\BouncyCastle-PCL\crypto\crypto.dotnet.csproj

If I remove the I get a further error about the TargetFrameworkIdentifier, so something is not right and I'm a bit lost as to what. A cursory google suggests we don't need that import unless we want to support VS 2010, which we don't particularly. I do have VS 2010 installed (with SP1) and installed Portable Library Tools just in case, but I still get this error. I think there's something in your environment that I'm missing.

[clairernovotny]

I think I know what it is.. When you installed 2015, did you do a custom or typical install? Unfortunately they excluded a lot of stuff from the typical install. Make sure to choose custom and select the windows 10 tools for uwp. Despite the name, that component includes the "modern pcl" support, which is what that dotnet version is using.

Those "v5" targets are from the new .NET Core portable projects.

[peterdettman]

I will try that, thanks for the hint

[peterdettman]

@onovotny Yep, that worked.

[clairernovotny]

Awesome! I really wish they picked better defaults

[peterdettman]

@onovotny There are some new commits in the pipe that pull a few changes from BouncyCastle-PCL that were missing PORTABLE-specific guards for parts. Please merge carefully!

Also I'm curious why crypto.tests.Net45 defines PCL and SILVERLIGHT. I removed these in favour of PORTABLE, which makes more sense and all the tests still run and pass here (but you might want to take the latest changes before testing this).

I've been trying to get the default (.NET 1.1) NAnt build to work inside BouncyCastle-PCL and after the latest changes, the remaining errors are all related to Close/Dispose, so I think that's the main obstacle left.

[clairernovotny]

All merged in and pushed.

[peterdettman]

A few minor nits: clairernovotny/BouncyCastle-PCL#10

[peterdettman]

@onovotny I've pushed some more PORTABLE commits. I think the merge into BouncyCastle-PCL will be pretty hairy, so it might be better if I do it and send you a PR?

[clairernovotny]

Sure, thanks. I'm at the MVP summit this week, so I couldn't merge till the weekend anyway.

[peterdettman]

@onovotny I've submitted a final roll-up PR to BouncyCastle-PCL. The trees are now essentially synchronised, so I expect future work can just proceed in bc-csharp.

[clairernovotny]

Sounds good to me. I just merged it in. LMK when you're ready and I can release a final 1.8.0 PCL release. I can also add you as an owner to the NuGet package.

When you're ready, I'd suggest turning Portable.BouncyCastle into a blank package (without libs) that simply has a dependency on the regular BC nuget so that when ppl update it'll pull in the real one.

The last thing to do is to eventually support the netstandard* TFM's in the NuGet but the tooling from Microsoft isn't ready yet. Once that's done I can jump in if you'd like.

[peterdettman]

Yeah, a final 1.8.0 of the existing PCL release would be great to tide us over while we sort ourselves out with NuGet. Please wait until the release goes up on http://www.bouncycastle.org/csharp in the next day or so, and perhaps until after we announce on dev-crypto-csharp mailing list, as there is an important release note (see crypto/Readme.html) for 1.8.0 regarding a breaking change for the Serpent cipher; ideally you could include that note somewhere prominent for the PCL release too.

[clairernovotny]

The 1.8.0 PCL release is now live: http://www.nuget.org/packages/Portable.BouncyCastle/1.8.0