Drop support for signed version

[danielmarbach]

I plan to drop support for the signed version. It doesn't make sense to have a signed version of a test library in my point of view. Any objections and arguments?

[DerAlbertCom]

I don't need it. On the other side, it is only a build script change and has no additional work to do.

[danielmarbach]

I have it running now. Download rate of Signed version on nuget indicates that it is rarely used. Honestly I see no reason why you should have a signed test assembly, even InternalsVisibleTo should work with unsigned test assemblies.

[NameOfTheDragon]

Unsigned test assemblies isn’t the issue, it is where your production assembly is signed. I believe that if your test assembly references a signed assembly (which in some COM interop situations it must be) then you can’t do InternalsVisibleTo unless you also sign the test assembly. Be careful here, you might shoot yourself in the foot. Why was the signed version originally introduced?

--Tim Long

From: danielmarbach [mailto:notifications@github.com]
Sent: 19 December 2013 22:38
To: machine/machine.specifications
Subject: Re: [machine.specifications] Drop support for signed version (#190)

I have it running now. Download rate of Signed version on nuget indicates that it is rarely used. Honestly I see no reason why you should have a signed test assembly, even InternalsVisibleTo should work with unsigned test assemblies.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/190#issuecomment-30973505.

ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=rBLGZO77019959&from=tim@tigranetworks.co.uk
Complete email hygiene and business continuity solution available from http://www.tigranetworks.co.uk

[danielmarbach]

I don't know. That's why I'm asking the community

Am 21.12.2013 um 17:37 schrieb NameOfTheDragon notifications@github.com:

Unsigned test assemblies isn’t the issue, it is where your production assembly is signed. I believe that if your test assembly references a signed assembly (which in some COM interop situations it must be) then you can’t do InternalsVisibleTo unless you also sign the test assembly. Be careful here, you might shoot yourself in the foot. Why was the signed version originally introduced?

--Tim Long

From: danielmarbach [mailto:notifications@github.com]
Sent: 19 December 2013 22:38
To: machine/machine.specifications
Subject: Re: [machine.specifications] Drop support for signed version (#190)

I have it running now. Download rate of Signed version on nuget indicates that it is rarely used. Honestly I see no reason why you should have a signed test assembly, even InternalsVisibleTo should work with unsigned test assemblies.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/190#issuecomment-30973505.

ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=rBLGZO77019959&from=tim@tigranetworks.co.uk
Complete email hygiene and business continuity solution available from http://www.tigranetworks.co.uk

—
Reply to this email directly or view it on GitHub.

[NameOfTheDragon]

I can’t make an authoritative argument either way, but some of the stuff I work on (ASCOM drivers mainly, see http//ascom-standards.org) requires registering assemblies for COM Interop, but the assemblies are not installed in the GAC, so the CodeBase must be set. The equivalent is using RegAsm.exe /codebase – and this requires the assembly to be signed. Therefore, the test assembly must be signed too, otherwise InternalsVisibleTo can’t be used. This is a fairly unusual situation, accounting for the low number of downloads for the signed package. I wouldn’t use signed if I didn’t have to, but dropping it just like that makes me nervous.

I think I personally can probably work around the strong-name signing requirements, but unless there is a compelling reason to drop the signed version, I would vote to keep it around until we fully understand the implications. What if you declare it ‘deprecated’ and see if anyone complains?

[danielmarbach]

Thanks @NameOfTheDragon for the input. I will not drop anything just like that. I want to use this issue as a discussion. I want to make the project progressing. This sometimes means getting rid of "old" stuff. But in that case I think I already have a better idea to support it without the current csproj patching stuff in the rake build script. And by the way: I just checked the scenario you described again. It's true when you have a signed assembly with an InternalsVisibleTo attribute to a specification assembly the specification assembly needs to be strong named too. I'm closing this issue. Thanks for the open discussion!

[NameOfTheDragon]

I've worked out that the signing issues can be bypassed, at least in the projects I work on. One can define a preprocessor symbol such as 'SIGNASSEMBLIES' in appropriate build configurations and then use something like this in AssemblyInfo.cs:

// Strong-name signing, only performed for release builds.
#if SIGNASSEMBLIES
[assembly: AssemblyKeyFile(@"..\StrongNameKey.snk")]
#endif

In the Configuration manager, the test assemblies can be set to build only for build configurations where the signing is NOT performed (i.e. SIGNASSEMBLIES is not defined). And therefore the unsigned MSpec assemblies can be used.

On that basis, I would be happy for you to drop the -signed assemblies.

[danielmarbach]

Thanks for the feedback. I have a solution now which doesn't require to patch the csproj. I could remove a lot of rake code. It is now a none issue for me. Let me explain why I raised this issue: I'm working on a common build script which uses conventions. The common build script can then be used for the multi repo split out. I progressed a lot and the output can be observed in the development repo. The final goal is that each splitout repo can reference the development nugets and therefore got all conventions they need to be built (including Gemfile, rake script etc.). When I update the build stuff I just bump the nuget package version and get the updates in all repos.

Am 16.01.2014 um 06:23 schrieb Tim Long notifications@github.com:

I've worked out that the signing issues can be bypassed, at least in the projects I work on. One can define a preprocessor symbol such as 'SIGNASSEMBLIES' in appropriate build configurations and then use something like this in AssemblyInfo.cs:

// Strong-name signing, only performed for release builds.
#if SIGNASSEMBLIES
[assembly: AssemblyKeyFile(@"..\StrongNameKey.snk")]
#endif
In the Configuration manager, the test assemblies can be set to build only for build configurations where the signing is NOT performed. And therefore the unsigned MSpec assemblies can be used.

On that basis, I would be happy for you to drop the -signed assemblies.

—
Reply to this email directly or view it on GitHub.