John Allberg
2013-02-11 04:04:14 UTC
Hi!
To be able to use internal classes from the test project you can use the InternalsVisisbleTo attribute. Quite handy... :)
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx
Just put it in your assemblyinfo and point out the test library.
Best Regards,
John
* To: dev-crypto-csharp-***@public.gmane.org<mailto:dev-crypto-csharp%40bouncycastle.org>
* Subject: Re: [dev-crypto-csharp] For c# codebase, why are tests compiled into the library itself?
* From: Peter Dettman <pkd-PQo3LEzKn7yGw+***@public.gmane.org<mailto:pkd%40lockboxlabs.com>>
* Date: Tue, 05 Feb 2013 10:56:05 +0700
* Delivered-to: bouncy-hNDzWkKOYQVkjEdtE6O+2bdltv/***@public.gmane.org
* In-reply-to: <05f801ce0323$84f042c0$8ed0c840$@gmail.com<http://www.bouncycastle.org/csharpdevmailarchive/msg00594.html>>
* List-id: <dev-crypto-csharp-***@public.gmane.org>
* List-unsubscribe: <mailto:dev-crypto-csharp-leave-***@public.gmane.org?subject=unsubscribe>
* References: <05f801ce0323$84f042c0$8ed0c840$@gmail.com<http://www.bouncycastle.org/csharpdevmailarchive/msg00594.html>>
* User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
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 viaAssembly.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
To be able to use internal classes from the test project you can use the InternalsVisisbleTo attribute. Quite handy... :)
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx
Just put it in your assemblyinfo and point out the test library.
Best Regards,
John
* To: dev-crypto-csharp-***@public.gmane.org<mailto:dev-crypto-csharp%40bouncycastle.org>
* Subject: Re: [dev-crypto-csharp] For c# codebase, why are tests compiled into the library itself?
* From: Peter Dettman <pkd-PQo3LEzKn7yGw+***@public.gmane.org<mailto:pkd%40lockboxlabs.com>>
* Date: Tue, 05 Feb 2013 10:56:05 +0700
* Delivered-to: bouncy-hNDzWkKOYQVkjEdtE6O+2bdltv/***@public.gmane.org
* In-reply-to: <05f801ce0323$84f042c0$8ed0c840$@gmail.com<http://www.bouncycastle.org/csharpdevmailarchive/msg00594.html>>
* List-id: <dev-crypto-csharp-***@public.gmane.org>
* List-unsubscribe: <mailto:dev-crypto-csharp-leave-***@public.gmane.org?subject=unsubscribe>
* References: <05f801ce0323$84f042c0$8ed0c840$@gmail.com<http://www.bouncycastle.org/csharpdevmailarchive/msg00594.html>>
* User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
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 viaAssembly.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