Fix: Could not load System.CodeDom exception with xRetry.Reqnroll plugin

[gasparnagy]

🤔 What's changed?

When the code-behind generation runs on .NET Framework (e.g. when the project is built from Visual Studio), the assembly versions are verified strictly, so if a dependency of the Reqnroll generator is updated (e.g. System.CodeDom or Gherkin), the plugins that were compiled for an earlier version fail, although they would be compatible with the new dependency.

The solution is to hook on the assembly resolve event and if the same assembly has been loaded already, we use the loaded one even if the version number is different.

⚡️ What's your motivation?

Fixes #310: Could not load System.CodeDom exception with xRetry.Reqnroll plugin.

🏷️ What kind of change is this?

• 🐛 Bug fix (non-breaking change which fixes a defect)

♻️ Anything particular you want feedback on?

n/a

📋 Checklist:

• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• Users should know about my change
  • I have added an entry to the "[vNext]" section of the CHANGELOG, linking to this pull request & included my GitHub handle to the release contributors list.

---

This text was originally taken from the template of the Cucumber project, then edited by hand. You can modify the template here.

[clrudolphi]

Doesn't this open Reqnroll to some risk that such easy acceptance of prior versions will result in hard-to-diagnose bugs when backward compatibility isn't perfect?
Do we need to now enhance our testing to include prior versions of common dependencies?
I suppose the relevant question is: what are the alternatives here?

• Could we require plugins to use version ranges on their dependencies that Reqnroll might also load?
• Could we limit Reqnroll's prior release acceptance to Microsoft-issued assemblies (such as those in the System.* namespace) under the assumption that those are most likely to be backward compatible while protecting Reqnroll from conflicts caused by 3rd party assemblies?

[gasparnagy]

@clrudolphi when you build with dotnet build, these dependency version differences are anyway ignored by the framework, so the issue is really about building from Visual Studio.

In general this is more of an issue with commonly used external plugins, becase we anyway release a new version of our own plugins with a new Reqnroll version.

I don't think we can restrict the dependency compatibility with version number ranges. The System.CodeDom jumped from v4 to v8 and it seems to be fully backward compatible. Also we recently upgraded Gherkin v29 to v30 which is also backwards compatible, but would still cause a similar issue with xRetry (and similar generator plugins).

I think we should do what you say. For these well-known external plugins we should have a test to be able to get notified about compatibility issues. This PR adds such a test for xRetry.Reqnroll v1.0.0. We can follow this pattern for any others as they become known.