Scope binding doesn't work after migration from Specflow (Ambiguous Steps)

[JFFby]

Reqnroll Version

2.4.1

Which test runner are you using?

MSTest

Test Runner Version Number

3.8.3

.NET Implementation

.NET 8.0

Test Execution Method

Visual Studio Test Explorer

Content of reqnroll.json configuration file

For now it is stil specflow.json
{
"runtime": {
"missingOrPendingStepsOutcome": "Error"
}
}

Issue Description

After migrating from SpecFlow 3.9.74 to Reqnroll 2.4.1, I started seeing "Ambiguous Steps" errors for some step definitions. The Scope attribute, with different tags and features, does not seem to take effect.

[Binding]
[Scope(Tag = "tag1", Feature = "feature1")]
public class C1{
[Given("Some action")]
public void Step(){}
}

[Binding]
[Scope(Tag = "tag2", Feature = "feature2")]
public class C2{
[Given("Some action")]
public void Step(){}
}

SpecFlow extension for VS is disabled and Reqnroll extension is installed.
Where should I look to solve\debug this issue?

Link to Repro Project

No response

[304NotModified]

Could you please list the used packages in your project?

And please clear your obj/bin folders

[clrudolphi]

I cannot recreate with a simple example.
@JFFby can you post a reproduction project?

[JFFby]

Unfortunately, I can't post reproduction project. I can't reproduce this behavior on a new project. And obviously I can't post the project I am working on.

Also I noticed, that Before/AfterScenario hooks work fall all tests from all step definition files. For example, I have 3 feature files with 3 tests in each. In the logs I see, that for every test all 3 BeforeScenario and 3 AfterScenario are called

Is there a way to trace why Reqnroll works this way?
Everything works well on SpecFlow 3.9.74

[gasparnagy]

Is the Scope attribute used from the Reqnroll namespace (Reqnroll.ScopeAtterbute)?

Do you use the SpecFlow compatibility package?

[jmwulkan]

I ran into this issue too. I was using the SpecFlow compatibility package. I switched to use the Reqnroll namespace instead and the Scope attributes now work as expected.

[gasparnagy]

That sounds like a good workaround

[clrudolphi]

I believe the problem is in the BindingSourceProcessor GetScopes() method

        private IEnumerable<BindingScope> GetScopes(IEnumerable<BindingSourceAttribute> attributes)
        {
            return attributes.Where(attr => attr.AttributeType.TypeEquals(typeof(ScopeAttribute)))
                .Select(attr => new BindingScope(attr.TryGetAttributeValue<string>("Tag"), attr.TryGetAttributeValue<string>("Feature"), attr.TryGetAttributeValue<string>("Scenario")));
        }

This method takes a list of Binding attributes that have been applied to a member and filters them down to those that are Reqnroll.ScopeAttribute.

But in this situation, the ScopeAttribute is actually of type Techtalk.SpecFlow.ScopeAttribute.

Because of this mismatch, the Scope is not recognized and the binding methods are treated as if they had no scope (and thus an ambiguous match results).

Is this worth fixing?
If so, would the appropriate fix be to use the BindingReflectionExtensions IsAssignableFrom method instead of the TypeEquals method?