elsa-core/test/unit/Elsa.Features.UnitTests/Elsa.Features.UnitTests.csproj

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <Include>[Elsa.Features]*</Include>
        <Threshold>0</Threshold>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Microsoft.Extensions.DependencyInjection"/>
    </ItemGroup>

    <ItemGroup>
        <ProjectReference Include="..\..\..\src\common\Elsa.Features\Elsa.Features.csproj"/>
    </ItemGroup>

</Project>
fix(features): support features introduced during Module.Apply() (#7966) Module.Apply() enumerated _features.Values directly while calling feature.Apply(). A feature whose Apply() introduces another feature — Module.Configure<T>() directly, or via a helper such as AddActivity<T>() which configures WorkflowManagementFeature — mutated that collection mid-enumeration and threw "Collection was modified; enumeration operation may not execute", naming nothing about features. Whether it fired depended on whether the other feature happened to be installed already, so a module built or did not based on unrelated host config. The module already treats introduction-during-apply as supported: the ConfigureFeature loop iterates a snapshot for exactly this reason, and Configure<T>() has an _isApplying branch that creates, resolves and configures a feature introduced mid-Apply. Only the final apply loop missed the same treatment, so make it tolerant rather than diagnose a constraint the code does not hold. The apply loop now runs in rounds until no new features appear, each round topologically sorted so a late feature's dependencies apply before it. Hosted services are registered in a single pass after that loop, then moved back to the index the block previously occupied: registering late is needed so features contributed during Apply() are included and ordered by priority, while keeping the position matters because features register hosted services directly from Apply() — WorkflowRuntimeFeature adds DrainOrchestratorHostedService that way — and module-managed services must keep starting first, or a priority such as ActivateTenants at -1 would silently start ordering after them. Adds Elsa.Features.UnitTests, covering the introduced feature applying, a three-deep introduction chain, dependency ordering, hosted service registration and priority ordering for late arrivals, the installed- feature registry, and no double-apply, plus guards for pre-existing ordering behaviour. Closes #7944 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-08-20 21:53:07 +00:00			`<Project Sdk="Microsoft.NET.Sdk">`

			`<PropertyGroup>`
			`<Include>[Elsa.Features]*</Include>`
			`<Threshold>0</Threshold>`
			`</PropertyGroup>`

			`<ItemGroup>`
			`<PackageReference Include="Microsoft.Extensions.DependencyInjection"/>`
			`</ItemGroup>`

			`<ItemGroup>`
			`<ProjectReference Include="..\..\..\src\common\Elsa.Features\Elsa.Features.csproj"/>`
			`</ItemGroup>`

			`</Project>`