I noticed that if currently ALL the tests for Bouncy Castle are compiled into the library DLL itself (instead of a separate library test .DLL). This can be an unnecessary drain for projects that use/include the BouncyCastle library (crypto.dll) since the consuming application doesn't really care about the tests and all the static test vectors it brings.
I quickly extracted out the tests Before: crypto.dll: 5.4 MB crypto-test.exe: 16KB After: crypto.dll : 1.4 MB (380% / 3.8x better) crypto-test.exe: 4MB The changes are actually quite trivial: 1. Move entire \test\ folder from 'crypto' project into 'crypto-test' project (drag drop in VS2012, it will fix the build include .cs file list in both projects) 2. Right click 'crypto-test' -> properties -> application tab -> startup object -> choose crypto_test.CryptoTest (to resolve multiple Main() entry points) 3. Inside src\util\platform.cs replace all 'internal' protection levels with 'public' protection levels 4. Removed references to nunit* in crypto project 5. Added the above nunit* references to crypto-test project 6. Rebuild both projects / solution Question: Apart from insufficient time (which I totally get), is there another reason these have been included in the library itself? Some tests do fail because they are hardcoded to expect embedded test data inside the library .dll and then fetch it via Assembly.GetExecutingAssembly().GetManifestResourceStream(fullName); //fullname=filename of resource embedded into .dll eg: "masterlist-content.data"). This is more of a test design issue than anything else. Peter, side question: Is there any plan to migrate from CVS to GIT? IMHO GIT > CVS for branching and distributed development; plus GitHub amplifies that GIT advantage too. Just asking. Thanks Sid
