Support for .NET 10 / planned release timeline

[imiljkovic]

Hi,

Thank you for the great project and continued maintenance of WorkflowCore.

I wanted to ask whether there is a planned release timeline for official .NET 10 support.

We encountered issues during workflow execution related to runtime expression compilation (InvalidProgramException coming from DefinitionLoader.BuildScalarInputAction).

Could you share:

• whether .NET 10 support is officially planned,
• if there is an ETA for a release,
• and whether there are known issues with dynamic expression compilation/workflow DSL on .NET 10?

Thanks!

[danielgerlag]

Hi, thanks for the report!

We've opened #1429 which adds .NET 10 to our test matrix and pre-compiles dynamic expressions outside closures in \DefinitionLoader\ (the pattern most likely to produce \InvalidProgramException\ on newer runtimes).

However, our existing unit tests pass on .NET 10 both before and after the fix, so we haven't been able to reproduce the exact failure you're seeing.

Could you share:

• The workflow definition (JSON or YAML) that triggers the \InvalidProgramException?
• The full stack trace?

That would let us add a targeted regression test and confirm the fix addresses your scenario. Thanks!

[danielgerlag]

Regarding the general .NET 10 support questions:

The core libraries (\WorkflowCore, \WorkflowCore.DSL, etc.) target
etstandard2.0, which means they are inherently compatible with any .NET runtime including .NET 10 no retargeting is needed.

With #1429 we're also adding
et10.0\ to our test projects so that our CI validates against .NET 10 going forward.

[imiljkovic]

@danielgerlag Thank you.

Here is the stack trace:

System.InvalidProgramException: Common Language Runtime detected an invalid program.
   at System.Runtime.CompilerServices.RuntimeHelpers.CompileMethod(RuntimeMethodHandleInternal method)
   at System.Runtime.CompilerServices.RuntimeHelpers.CompileMethod(RuntimeMethodHandleInternal method)
   at WorkflowCore.Services.DefinitionStorage.DefinitionLoader.<>c__DisplayClass14_0.<BuildScalarInputAction>g__acn|0(IStepBody pStep, Object pData, IStepExecutionContext pContext)
   at WorkflowCore.Services.WorkflowExecutor.ExecuteStep(WorkflowInstance workflow, WorkflowStep step, ExecutionPointer pointer, WorkflowExecutorResult wfResult, WorkflowDefinition def, CancellationToken cancellationToken)
   at WorkflowCore.Services.WorkflowExecutor.Execute(WorkflowInstance workflow, CancellationToken cancellationToken)

Here is the relevant step definition:

{
            "Id": "UpdateStatus",
            "Name": "Update internal status",
            "StepType": "...",
            "Inputs": {
                "MessageId": "data.MessageId",
                "Status": "\"waits-for-batching\""
            },
            "NextStepId": "WaitingForEvent"
        }

As you can see, this is just a simple variable binding and a string literal input.

[imiljkovic]

Hi @danielgerlag,

When can we expect a new release version? Any updates on this topic?

[danielgerlag]

Thanks for the stack trace and the step definition — that was exactly what we needed.

I've added a targeted regression test to #1429 that mirrors your scenario precisely: a scalar variable-binding input (data.MessageId) plus a scalar string-literal input ("waits-for-batching"). It loads the definition and assigns the inputs the same way WorkflowExecutor.ExecuteStep does, then asserts both values resolve.

One thing worth flagging: I couldn't reproduce the InvalidProgramException itself on any GA or servicing .NET 10 build. I ran your exact case against the unfixed code across 10.0.0-preview.1/.4/.6/.7, 10.0.0 GA, and 10.0.10, on both arm64 and x64, including with tiered compilation disabled — every combination succeeded. The exception originates in the JIT (RuntimeHelpers.CompileMethod), so it looks tied to a specific runtime build/architecture rather than the workflow definition itself.

Regardless, #1429 is the right fix: the input/output expressions were being compiled inside a closure and recompiled on every invocation. Pre-compiling them once at definition-load time removes that fragile pattern (the likely JIT trigger) and is also a nice perf win.

To help me confirm what you hit, could you share the output of dotnet --info (SDK + runtime build, OS, architecture)? If you're on an early .NET 10 build, a runtime servicing update may already resolve it on its own.

The fix will ship in the next release once #1429 is merged.

[imiljkovic]

@danielgerlag Any ideas when the next release will happen?

[mm-t1]

Hello! Could we expect PR 1429 to be merged soon? Any plans for the next release? @danielgerlag

[wfcore-manager]

Sorry for the wait.

#1429 is the .NET 10 fix (expression pre-compilation + net10.0 on the test matrix). I'm working on getting that merged next; it will ship in the following release. I'll post here once it's on NuGet.

No change to the earlier note: core libraries already target netstandard2.0, so they're usable on .NET 10 today. #1429 is the hardening + official CI coverage.

Current merge blockers on #1429: waiting on a code owner review from glucaci, and Elasticsearch-Tests is red (that job also flakes on master).

[wfcore-manager]

3.19.0 is tagged: https://github.com/danielgerlag/workflow-core/releases/tag/v3.19.0

It includes the #1429 .NET 10 expression compilation fix. NuGet publish is in progress — I'll update here when WorkflowCore 3.19.0 is on nuget.org.

[wfcore-manager]

WorkflowCore 3.19.0 is on NuGet: https://www.nuget.org/packages/WorkflowCore/3.19.0