Add assembly signing

[YuliiaKovalova]

In order to resolve the problem

Assembly signing was added. More info is here: https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named#why-strong-name-your-assemblies

[YuliiaKovalova]

pull the changes from https://github.com/bytecodealliance/wasmtime-dotnet/pull/317 to have a green build

[jsturtevant]

What's the scenario you are using and seeing this error?

Strong naming has no benefits on .NET Core/5+. C# compiler produces CS8002 warning for strong-named assemblies referencing non-strong named assemblies. It is fine to suppress this warning for libraries that target .NET Core/5+ only.

[rainersigwald]

@jsturtevant We're interested in using this library, but because our assemblies are strong-named signed for historical and .NET Framework reasons, we are disallowed from referencing it by the a-strong-named-assembly-may-not-reference-a-non-strong-named-assembly rule. Since the strong name is mostly harmless, the usual solution to this problem is to strong-name the assembly with a new key that is checked into the repo, so any build can access the private key.

[jsturtevant]

Thanks! It does seem Microsoft recommends checking the signed key https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming#create-strong-named-net-libraries

This guidance is specific to publicly distributed .NET libraries, such as .NET libraries published on NuGet.org. Strong naming is not required by most .NET applications and should not be done by default. ✔️ CONSIDER strong naming your library's assemblies. ✔️ CONSIDER adding the strong naming key to your source control system. A publicly available key lets developers modify and recompile your library source code with the same key.

After we sort out the current build issues, I think we can move forward with this approach.