IUnitTestRuntimeProvider injection fails in combination with SolidToken.SpecFlow.DependencyInjection

[jeromv]

SpecFlow Version

3.9.5

Which test runner are you using?

xUnit

Test Runner Version Number

16.11.0

.NET Implementation

.NET 5.0

Project Format of the SpecFlow project

Sdk-style project format

.feature.cs files are generated using

SpecFlowSingleFileGenerator custom tool

Test Execution Method

Visual Studio Test Explorer

SpecFlow Section in app.config or content of specflow.json

No response

Issue Description

IUnitTestRuntimeProvider injection fails when I use SolidToken.SpecFlow.DependencyInjection.

Steps to Reproduce

just run the calculator feature in the attached project file

Link to Repro Project

https://drive.google.com/file/d/1vaRNM3Y06VBgBS8j4ef2_ctazBQNTdel/view?usp=sharing

[jeromv]

when "SolidToken.SpecFlow.DependencyInjection" is being used the automatic IUnitTestRuntimeProvider injection no longer works.

Add services.AddTransient<IUnitTestRuntimeProvider, XUnitRuntimeProvider>(); to the class that implements the [ScenarioDependencies] and it works again. So I am not sure if this is a bug or not. For you to decide :-)

[SabotageAndi]

This is strange. We register the UnitTestRuntimeProviders in the global container, which AFAIK can't be overwritten via a different DI container. @gasparnagy Any idea what happens here? You added the functionality to support different DI frameworks.

[gasparnagy]

Good question. The only thing I can think of is related to the load sequence of the plugins. The xunit provider is loaded by the SpecFlow.xUnit plugin and it can happen that the SolidToken plugin resolves something too early.

[jeromv]

Two plugins fighting for privilege 🙂. I am happy there is an easy work around 😇

Op di 14 sep. 2021 17:57 schreef Gáspár Nagy @.***>:

Good question. The only thing I can think of is related to the load sequence of the plugins. The xunit provider is loaded by the SpecFlow.xUnit plugin and it can happen that the SolidToken plugin resolves something too early.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SpecFlowOSS/SpecFlow/issues/2488#issuecomment-919286844, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCZCMDYJZ6PFXBAMXQUTFDUB5WFHANCNFSM5DBIVVFQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mbhoek]

Hey @jeromv if you're still experiencing this issue please let me know at https://github.com/solidtoken/SpecFlow.DependencyInjection/issues

[jeromv]

I am not using specflow at the moment because i am working on a different project for another company. If i remember correctly i fixed this by registering one of the interfaces myself. So there was an easy solution to the problem. Too long ago now to remember the details, i am sorry...

Op vr 2 dec. 2022 17:51 schreef Mark Hoek @.***>:

Hey @jeromv https://github.com/jeromv if you're still experiencing this issue please let me know at https://github.com/solidtoken/SpecFlow.DependencyInjection/issues

— Reply to this email directly, view it on GitHub https://github.com/SpecFlowOSS/SpecFlow/issues/2488#issuecomment-1335526852, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCZCMDESPGB35AZDZ3F3XLWLISIZANCNFSM5DBIVVFQ . You are receiving this because you were mentioned.Message ID: @.***>