Repository navigation
Add strong key #77
Description
Activity
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).
FastExpressionCompileris not strong-signed so you cannot reference it. I think other tools for testing, e.g. NUnit, are strong-signed andExpressionToCodeLibshould be too.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?
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=nullI 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
ExpressionToCodepopularity it should be that most do expect, hence I looked into assemblies used along with tests, may be other tooling.@dadhi any opinion?
There is two options:
- You include FEC as a code file instead of package, and release a ETCL.Signed version
- I am creating FEC.Signed, repeat.
It seems that 2nd is inevitable, but I wanted to postpone it as far as possible.. sigh
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.
I though users can use StrongNameSigner regardless of what the nuget packages do? But I get that it would be convenient for them...
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'dHaving 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.
Reacted by 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.