feat: strong names for published assemblies

[delatrie]

Context

The PR introduces strong names for assemblies of the following packages:

• Allure.Net.Commons
• Allure.NUnit
• Allure.Reqnroll

Other packages can't use strong names because they rely on Lib.Harmony, which isn't strong-named. These are:

• Allure.SpecFlow (uses harmony for selective run, see Allure-specflow: selective run support #392).
• Allure.Xunit (uses harmony to report complex parameters of some theories and for selective run; see Replace allure-xunit's custom attributes with runner reporter (fixes #344) #366 and Selective run support: commons, nunit, xunit #390).

Since SpecFlow is already deprecated by Tricentis, it's unlikely we'll implement strong names for Allure.SpecFlow.

As for Allure.Xunit, it's currently incompatible with .NET Framework, which is an issue on its own (see #589) and should be addressed first. Then, once we find a replacement for harmony (#369), we can make Allure.Xunit strong-named.

Signing and AspectInjector

We use Aspect Injector to implement [AllureStep], [AllureBefore], [AllureAfter] and some other aspects. The way it works makes the assembly's signature invalid. Such a signature should then be updated with sn.exe, which is a part of the Visual Studio installation on Windows machines. Otherwise, loading the assembly on .NET Framework throws Could not load file or assembly '<assembly>' or one of its dependencies. Strong name signature could not be verified.

The PR updates the publishing workflow to run on Windows and to use vswhere.exe (which is a part of the windows-latest image) to locate the Visual Studio installation folder. It then uses the Developer PowerShell tool in that folder to locate sn.exe. The path to sn.exe is forwarded to an MSBuild target via the Allure_SnExePath property. The target runs after Aspect Injector changes the assembly. It updates the signature by calling sn.exe -Ra <assembly>. After that's done, the assembly passes the sn.exe -vf <assembly> check. The resigned assembly is uploaded to NuGet.

Resigning during development

This resigning routine isn't required during development because our test/sample projects target a modern .NET runtime (8.0 at the time), which doesn't verify strong names. If, for some reason, a developer needs valid signatures, they should set the Allure_SnExePath environment variable. Use ./build/findvstool.ps1 to find the correct path:

$Env:Allure_SnExePath = ./build/findvstool.ps1 sn.exe
dotnet build

Obviously, this only works (and makes sense) on Windows.

AspectInjector update

The PR updates AspectInjector to version 2.9.0, which runs natively on Apple Silicon. This makes the workaround added via #396 unnecessary, so the PR removes it as well.

Other changes

• Fix publish.yml job name to be publish.
• Set PackageReleaseNotes from publish.yml instead of Directory.Build.props.
• Rename the build workflow to test.
• Prefix all Allure-specific properties and target names with Allure_ in DirectoryBuild.targets to prevent collisions.

Closes #376
Closes #391

[darrenge]

Hey @delatrie any update \ ETA on when this PR will be pushed? Looking forward to it.

[delatrie]

@darrenge very soon. There are some minor msbuild-related fixes left that need to be applied. Hopefully, it will be done in a day or two.

[darrenge]

@delatrie -- when will this be released in nuget package vs just being in code base? Thanks for taking care of it.

[delatrie]

@darrenge will push it in a moment, sorry for the delay