Add strong key

[dzmitry-lahoda]

I have test project which is strongly signed. I know that having testing project strongly signed is stupid, but we have many of these and hope published ExpressionToCodeLib to be signed either.

Error	CS8002	Referenced assembly 'ExpressionToCodeLib, Version=2.5.1.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

[EamonNerbonne]

As an experiment; I pushed something as 2.6.0-signed. Does that work for you?

If so, I'm not sure exactly how I'm going to maintain that. If there are really no serious downsides to the normal workflow, I might enable this by default; but IIRC I used to strong-sign and stopped - and there probably was some reason (even if it escapes me at the moment).

[dzmitry-lahoda]

FastExpressionCompiler is not strong-signed so you cannot reference it. I think other tools for testing, e.g. NUnit, are strong-signed and ExpressionToCodeLib should be too.

[dzmitry-lahoda]

https://github.com/punker76/gong-wpf-dragdrop#strong-naming

[EamonNerbonne]

Strong naming is such a niche case; I don't think it's worth dropping the dependency on FastExpressionCompiler for that. If you want, I can make a single build without that dependency (say, a 2.7.0-signed), but I don't intend to support it very intensively - and even if I wanted too, since I never dogfood it, I might break it without noticing it.

So I think the suggestion you link to - to use a external tool to strong-name OSS nuget packages internally - is probably the best best; that allows you to do the same for any other OSS dependencies too.

And note that although nunit may be signed; common alternatives such as xUnit are not (I believe).

Is there any reason your test projects need to be strongly signed?

[dzmitry-lahoda]

I have checked some testing tools, 2 where signed, xunit among them, and 1 was not.

// xunit.execution.desktop, Version=2.3.1.3858, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c
// xunit.abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c
// TechTalk.SpecFlow, Version=2.3.0.0, Culture=neutral, PublicKeyToken=0778194805d6db41

//Unquote, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null

I think it is stupid to sign tests assemblies and I do not know reason why was done, but it will take time and bureaucracy to remove strong sign from our test projects.

Yep, I think I will strong sign manually or remove all sign of projects, but for ExpressionToCode popularity it should be that most do expect, hence I looked into assemblies used along with tests, may be other tooling.

[EamonNerbonne]

@dadhi any opinion?

[dadhi]

There is two options:

1. You include FEC as a code file instead of package, and release a ETCL.Signed version
2. I am creating FEC.Signed, repeat.

It seems that 2nd is inevitable, but I wanted to postpone it as far as possible.. sigh

[dadhi]

Mm, I've just forgot that I am including .snk file with DryIoc. I may do the same for FEC, or you may include your own. Then Users may use some StrongNameSigner or whatever.

[EamonNerbonne]

I though users can use StrongNameSigner regardless of what the nuget packages do? But I get that it would be convenient for them...

[SimonCropp]

the only reason to SN a test-helping lib, is because a test project is testing a SN'd project, and that target project exposes [InternalsVisibleTo] so non public member can be tested. So in this case all libs the test project pulls in need to be SN'd

Having said that. in most real cases where i have seen this:

• the target project is an application, and not consumed as a lib by other projects, so internals are redundant and the project can just make those types public so they can be tested. project should just make those internal members public
• the project is using SN for security despite the doco saying https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies

Do not rely on strong names for security. They provide a unique identity only.