Add shell middleware, call‑stack tracking, and workflow reference graph APIs (#7333)
* refactor(deps): use local CShells project refs
Replace CShells NuGet package references with direct project references to the local CShells source to enable developing and testing against local changes and simplify build integration across modules.
* Handle assembly load errors in feature discovery
Added error handling for assembly load failures in feature discovery to improve resilience. Also updated configuration for identity token options and removed unused service bus consumer dependencies. Simplified project structure by moving and cleaning up `Directory.Build.targets` files.
* Refactor configuration and service extension methods.
Moved `ShellSettingsExtensions` and `ShellConfiguration` to `CShells.Abstractions` for better modularity. Added new `ServiceCollectionFeatureExtensions` to improve options registration. Updated appsettings and references to support these changes.
* Introduce ManagementServiceCollectionExtensions to streamline activity and variable registration
Added `ManagementServiceCollectionExtensions` for registering Elsa activity types and variable descriptors, providing a modular and shell-feature-compatible approach to configuration. Updated relevant features to utilize these new extension methods, enhancing code modularity and reducing redundancy.
* Add resilience strategy registration to HTTP feature
Introduced `ResilienceServiceCollectionExtensions` to register resilience strategies within the `Elsa.Resilience.Core` module. Updated `HttpFeature` to incorporate resilience strategies, enhancing HTTP-related resilience configuration leveraging the new extension methods.
* Add new configuration options to JavaScriptFeature
Implemented multiple properties in `JavaScriptFeature` to enhance JavaScript execution: `AllowClrAccess`, `AllowConfigurationAccess`, `ScriptCacheTimeout`, `DisableWrappers`, and `DisableVariableCopying`. These additions enable more flexible and secure configuration of the Jint JavaScript engine.
* refactor(workflows): unify graph caching
Resolve workflow definitions first and store graphs under stable per-version-ID cache keys so different lookup paths share entries.
Centralize cache creation and change-token registration to remove duplicated caching logic.
Skip materializer-unavailable definitions to avoid caching null graphs and simplify flow.
* refactor(tests): centralize default IDs and materializer setup
Introduce constants for default definition and version IDs, and materializer name. Refactor tests to use these constants, streamline graph and definition resolution, and improve cache key creation by sharing logic across tests. Extend tests to check scenarios with unavailable materializers, ensuring caching only occurs for valid cases.
* extend(tests): enhance cache key verification in AutoUpdateTests
Added checks for both workflow definition and version cache keys in AutoUpdateTests to ensure comprehensive cache validation, improving test reliability and coverage.
* refactor(projects): update CShells project paths and solution configuration
Revised project reference paths in `Elsa.ModularServer.Web.csproj` for CShells projects and updated `Elsa.sln` to include new CShells projects, streamlining project organization and build configuration.
* Add `IWorkflowReferenceGraphBuilder` to `WorkflowManagementFeature`; rename `ResilienceShellFeature` to `ResilienceFeature`.
* Refactor `HttpFeature` to use `IMiddlewareShellFeature`, include `HttpWorkflowsMiddleware`, and update `HttpActivityOptions` defaults.
* Add `AddTypeAlias` and `AddVariableTypeAndAlias` extension methods to service collections
- Introduced `AddTypeAlias<T>` method in `ServiceCollectionExtensions.cs` for adding type aliases.
- Added `AddVariableTypeAndAlias<T>` method in `ManagementServiceCollectionExtensions.cs` to add variable types with aliases.
* Update CShells package versions to 0.0.11 and replace ProjectReferences with PackageReferences in project files
2026-02-28 20:16:04 +00:00
<Project>
<!-- Use project references instead of NuGet packages for local development -->
<PropertyGroup>
<UseProjectReferences>true</UseProjectReferences>
</PropertyGroup>
fix(build): make ConfigureAwait.Fody weaving actually take effect (#7983)
* fix(build): make ConfigureAwait.Fody weaving actually take effect
ConfigureAwait.Fody only rewrites awaits when it is handed an explicit
ContinueOnCapturedContext value. A bare <ConfigureAwait /> element parses
cleanly, emits no warning, and weaves nothing.
Of the 98 FodyWeavers.xml files under src/, only 22 set the attribute. The
other 76 carried a bare element, so those projects compiled with no weaving
at all while looking correctly configured. Verified on Debug net10.0 builds:
Elsa.Secrets (attribute set) referenced ConfiguredTaskAwaitable, while
Elsa.Alterations (bare element) did not.
Elsa ships as a library and can be hosted where a SynchronizationContext
exists, so weave everywhere rather than dropping the packages.
Fody reads the WeaverConfiguration MSBuild property in preference to any
FodyWeavers.xml, so the directive now lives in a single file, src/Fody.props,
alongside the package references it belongs with. All 98 per-project XML files
are deleted; they would otherwise be dead and misleading.
src/apps has its own props root that does not chain up to
src/Directory.Build.props, so it imports src/Fody.props directly instead of
redeclaring the Fody package references. This second gap was found by the
guard below, not by inspection.
Guard: Directory.Build.targets fails the build for any project that references
ConfigureAwait.Fody without an effective directive (ELSA0001) or that
reintroduces a FodyWeavers.xml alongside it (ELSA0002). Both were verified to
fire, including on the exact original bug shape.
The 22 already-weaving projects are unaffected: their effective directive is
identical before and after, and that set is disjoint from the four projects
holding explicit .ConfigureAwait( calls. All 25 such calls pass false, matching
what the weaver now applies, so they become redundant rather than contradictory
and are left in place.
Also repoints two security-assessment claims that cited the presence of
FodyWeavers.xml as evidence of weaving — the inference that masked this bug.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(build): drop FodyWeavers.xml from the new UserTasks modules
Merging main brought in eight new projects. Elsa.UserTasks carried a bare
<ConfigureAwait /> — the same latent no-op this branch removes elsewhere, added
while the fix was in review. Its seven persistence siblings set the attribute.
The guard caught it: ELSA0002 failed CI on the PR merge commit for all three
TFMs, on a file that never existed in the branch's own worktree.
All eight are redundant now that src/Fody.props supplies the directive.
Verified Elsa.UserTasks resolves it and its net10.0 build references
ConfiguredTaskAwaitable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 23:37:23 +00:00
<!--
Guards the ConfigureAwait.Fody directive declared in src/Directory.Build.props.
ConfigureAwait.Fody weaves nothing unless it is given an explicit ContinueOnCapturedContext
value, and it reports no warning when the value is absent. That is how 76 projects came to
ship with a FodyWeavers.xml containing a bare <ConfigureAwait /> and no weaving at all. These
checks make the same mistake a build failure rather than a silent no-op.
-->
<Target Name="ValidateConfigureAwaitDirective" BeforeTargets="CoreCompile">
<ItemGroup>
<_ConfigureAwaitFodyReference Include="@(PackageReference)" Condition="'%(Identity)' == 'ConfigureAwait.Fody'" />
</ItemGroup>
<PropertyGroup>
<_HasConfigureAwaitDirective Condition="'$(WeaverConfiguration)' != '' And $(WeaverConfiguration.Contains('ContinueOnCapturedContext="false"'))">true</_HasConfigureAwaitDirective>
</PropertyGroup>
<Error Condition="'@(_ConfigureAwaitFodyReference)' != '' And '$(_HasConfigureAwaitDirective)' != 'true'"
Code="ELSA0001"
Text="$(MSBuildProjectName) references ConfigureAwait.Fody, but the effective weaver configuration does not set ContinueOnCapturedContext="false", so the weaver rewrites nothing. Declare the directive in the WeaverConfiguration property (see src/Directory.Build.props), or drop the ConfigureAwait.Fody and Fody package references from this project." />
<Error Condition="'@(_ConfigureAwaitFodyReference)' != '' And Exists('$(MSBuildProjectDirectory)/FodyWeavers.xml')"
Code="ELSA0002"
Text="$(MSBuildProjectName) has a FodyWeavers.xml, which the WeaverConfiguration MSBuild property silently overrides. Delete the file; the ConfigureAwait directive belongs in src/Directory.Build.props only." />
</Target>
</Project>
