Strong name signing of assemblies #18
Conversation
| @@ -15,9 +16,18 @@ | |||
| <IsTestProject>$(MSBuildProjectName.Contains('Test'))</IsTestProject> | |||
| <IsBenchmarkProject>$(MsBuildProjectName.Contains('Benchmark'))</IsBenchmarkProject> | |||
| <IsPackable>false</IsPackable> | |||
| <TreatWarningsAsErrors>true</TreatWarningsAsErrors> | |||
There was a problem hiding this comment.
No errors (in local build) 😃
Edit: ah shit, Debug build, hence no XML comments...CI fails. Will have a look.
Shall we keep it enabled?
(Personally I prefer this -- on some projects, not always)
| } | ||
|
|
||
| public static bool Contains(this string instance, string value, StringComparison comparison) | ||
| => instance.IndexOf(value, comparison) >= 0; |
There was a problem hiding this comment.
I thought Contains is now more efficient, no?
There was a problem hiding this comment.
This is for .NET Standard 2.0 (see filename) as this the string.Contains API with the StringComparison is .NS 2.1.
string.Contains itself is exactely implemented in this way. More efficient on .NET Core is the IndexOf.
There was a problem hiding this comment.
There was a problem hiding this comment.
This file is only built iif .netstandard2.0, and there the rule shouldn't fire as the suitable overload doesn't exist.
I didn't see this analyzer warning. Did you get it?
For .NS 2.1 we use string.Contains(..., ignorecase) as it's cleaner to read.
Strong name signing
It's viral, so libraries that are itself strong-named can't used our lib if it's not signed.
Strong naming is no security measure, it's an artifact from the code sandbox security of old .NET days and not brought over to .NET Core. So it's OK to check the snk-file in (it is unique for this project, so no leaking of secrets, etc.)
Fixes #17
.NET Standard 2.0
Is enabled with this PR too, as the changes are minimal and broadens the potential target audience (if someone needs to stick to .NET Full and ASP.NET Core they deserve to get some goodness).