Strong name the assemblies in this package

[AArnott]

Closes #520

Remaining issues

Strong naming requires that all referenced assemblies are also strong named. Failure to comply with this emits a warning from the C# compiler and an assembly load failure at runtime on .NET Framework.
This repo has references to a few assemblies that are not strong named. So to succeed at strong naming this repo, we must first get the upstream dependencies strong named:

• CSC : warning CS8002: Referenced assembly 'EnumerableAsyncProcessor, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
• CSC : warning CS8002: Referenced assembly 'Sourcy.Core, Version=0.0.66.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
• CSC : warning CS8002: Referenced assembly 'trxparser, Version=0.5.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

While some of these are only dependencies of tests, and the tests would not strictly need to be strong named for your users, your repo uses InternalsVisibleTo, and a strong named assembly is only allowed to use InternalsVisibleTo to other strong named assemblies. So if you expose internals to your tests, you have to strong name them too.

[thomhurst]

Sourcy and EnumerableAsyncProcessor are my libraries too so I can easily accept a pr to strong sign them and push out a new version of each. Trxparser isn't mine though.

[AArnott]

I was able to filter the problem to just EnumerableAsyncProcessor, which thomhurst/EnumerableAsyncProcessor#134 will solve when merged and published.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[AArnott]

The EnumerableAsyncProcessor issue is now resolved, but now we have two new ones (OneOf, and Vogen.SharedTypes) which I've added to the PR description.

[thomhurst]

The EnumerableAsyncProcessor issue is now resolved, but now we have two new ones (OneOf, and Vogen.SharedTypes) which I've added to the PR description.

They're only used in the test example project. They aren't part of any packages. Should be okay?

[AArnott]

They're only used in the test example project. They aren't part of any packages. Should be okay?

That can make it OK, but if you have InternalsVisibleTo to that test assembly from a strong named project, then the test project must also be strong named. (aside: I have InternalsVisibleTo so bad... for several reasons).

In your case, it appears this restriction does not impact you, because you don't use IVT to this test project from a strong named project. Yay. I've pushed another update to remove the last two warnings.

[thomhurst]

I've just refactored so the only main project IVT usage is Core > Engine

#1857

[AArnott]

Alright then. I'll take another look.

[AArnott]

Simplifying change pushed.

[thomhurst]

Thanks @AArnott !