Well, it's sort of the way it fell into my lap oh so many years ago...
but some points:
- The release builds are actually done using NAnt at the command line
(compile-release/dist targets), and the tests are excluded from that. I
only really use the project files for development work.
- The tests are intended to have access to some things scoped as
'internal', though over time I've tried to reduce it, so I'm not sure if
it's an issue so much these days. If it's just Platform.cs as you say,
this may be easier than I thought.
- CVS->git is being discussed, but I can't offer you a timeline. I'm
fairly keen myself, as I see it as a way to lower the barriers for
getting other more knowledgable .NET developers to give me some help
with the build system, NuGet, and perhaps monitoring/testing things for
particular platforms (Mono, .NET CF, Silverlight, hopefully Portable
Class Library as of 1.8).
Yes, time is certainly in short supply.
Regards,
Pete Dettman
On 5/02/2013 5:03 AM, Sid Shetye wrote:
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
