real DI scoping

[shlomiassaf]

The current implementation is missing some of the goals of DI.

• It will create a new service container on every scenario (which might be slow)
  • It will build the service provider on every scenario (which might be slow)
• The above is true for Features as well, i.e. Injections from Features will not be the same as in Scenario!!!
• It does not provide singleton option in the DI, as the DI is built every time
• It does not dispose the service providers, it's not possible since it's always the root provider
• It does not provide scope resolution. I.E Feature based scoping vs Scenario based scoping
• Because a new container was created on every scenario, a new instance of the binding class was created, not allowing property share via instance.

---

This PR fixes scoping for Scenario and add support for Feature scoping.

With Scenario:

• The service container is now created and built ONCE for the entire run
• Singleton are now possible for the entire run.
• Each Scenario is now a real IServiceScope which is also disposed once the Scenario is done

With Feature:

• The service container is now created and built ONCE for the entire run
• Singleton are now possible for the entire run.
• Each Feature is a IServiceScope which is also disposed once the Feature is done
• All Scenarios are injected using the same scope, i.e. they share injections
• Feature hooks can now get injections shared with the injection of the Scenario

To use Feature scoping

[ScenarioDependencies(ScopeLevel = ScopeLevelType.Feature)]

The default is Scenario to ensure backward compatibility

[shlomiassaf]

@mbhoek I know it might look overwhelming, I hope you invest the time to get into it, because this is a big improvment.

[mbhoek]

@shlomiassaf Thank you for your contribution! I'm currently busy working on another project, but will have time to review your PR during the upcoming holidays. Sorry for the delay!

[mbhoek]

Hello @shlomiassaf, I finally found some time to review your PR and I think it's excellent work. I'm going to include in the next big update of this plugin, which will also include fixes for #75. I'd like to combine those fixes so I want to merge your work into a different branch next instead of main. I'm moving forward with this assuming you are okay with this. Thanks again!

[shlomiassaf]

I appreciate your update.
Looking forward for it, we're working with a side branch.

[mbhoek]

I just realized if I merge your work into a separate branch, and then later merge it into main, you would not get the proper attribution/credits in the 'Contributors' section on GitHub. So I'm going to have to rethink this.

[shlomiassaf]

Don’t worry about it Just do it

…

Sent from my iPhone

On 13 Mar 2022, at 17:32, Mark Hoek ***@***.***> wrote:  I just realized if I merge your work into a separate branch, and then later merge it into main, you would not get the proper attribution/credits in the 'Contributors' section on GitHub. So I'm going to have to rethink this. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[mbhoek]

I think contributions to open source projects should be properly contributed, I really appreciate you spending your valuable time on this. After giving it some thought the solution was pretty simple; enabling pre-release versions of the package allows me to complete PRs without publishing a release version.

Switching your PR back to main.

[mbhoek]

Looks good to me!

[mbhoek]

Thanks again for your excellent work @shlomiassaf -- your contribution is now part of the latest preview release.