Is Elsa 3.7.1 compatible with ASP.NET Zero 10.0.0? Should I upgrade before integrating Elsa?

[Ayisha957]

Hello,

I am working on an existing ASP.NET Zero application with the following setup:

• ASP.NET Zero: 10.0.0
• ASP.NET Boilerplate (Abp): 10.0.0
• Abp.Zero.Common: 10.0.0
• .NET: 9.0
• UI: ASP.NET MVC
• Database: SQL Server
• Multi-tenancy: Yes

I am currently integrating Elsa 3 manually and have installed:

• Elsa 3.7.1
• Elsa.Identity 3.7.1
• Elsa.Workflows.Api 3.7.1
• Elsa.Persistence.EFCore.SqlServer 3.7.1

My goal is to use Elsa for approval workflows in an existing Letter of Credit module.

I would like to clarify the following:

1. Is Elsa 3.7.1 compatible with ASP.NET Zero 10.0.0?

2. Is there an official Elsa integration available for ASP.NET Zero, or is the newer Elsa integration only for the modern ABP Framework (Volo.Abp)?

3. If a newer ASP.NET Zero version provides Elsa integration, should I upgrade my existing ASP.NET Zero application before continuing with my Elsa integration?

4. If I upgrade ASP.NET Zero, will the Elsa packages that I manually installed (Elsa 3.7.1) cause NuGet/package conflicts with the official integration?

5. Should I remove my manually installed Elsa packages before upgrading?

6. My application uses ASP.NET Zero multi-tenancy with separate databases for tenants. I want Elsa's persistence tables to be created in each tenant's database.

Is this architecture supported?

7. Should Elsa have its own EF Core DbContext and migrations while using the tenant's existing database connection?

8. What is the recommended approach for an existing ASP.NET Zero application:

   • Continue with manual Elsa 3.7.1 integration
     OR
   • Upgrade ASP.NET Zero first and then use the official Elsa integration?

I would appreciate any advice before I continue because this is an existing application and I want to avoid package and database migration conflicts.

Thank you.

[sfmskywalker]

Short answer: Elsa 3.7.1 supports .NET 9, but we do not certify a particular ASP.NET Zero release or ship an Elsa-owned ASP.NET Zero integration package. Treat this as an application integration you need to validate in your own host rather than as a supported package pairing.

ASP.NET Zero now has its own Elsa 3 integration material for newer releases. In particular, its current 15.3 sample uses a separate Elsa Server process alongside the ASP.NET Zero host, specifically avoiding direct composition of the Elsa/FastEndpoints stack into the ABP/Castle container. That is vendor guidance, not an Elsa package that should be installed into an existing application.

For an existing ASP.NET Zero 10 application, I would not recommend a platform upgrade solely to make the manually installed Elsa packages work. The two reasonable paths are:

1. Keep the current application and prove the integration in a small branch/prototype, preferably with a separate Elsa Server and an explicit authentication/tenant bridge.
2. If you already want the ASP.NET Zero upgrade for its own support and platform reasons, upgrade first in a separate branch and then adopt its current Elsa 3 sample architecture. Do not combine a hand-configured in-process Elsa stack with a version-pinned vendor sample: choose one registration/composition root and inspect its resolved NuGet graph.

On multi-tenancy and SQL Server persistence: Elsa 3.7.1 does support tenant-aware persistence and provider-selected connection strings. The SQL Server provider accepts a Func<IServiceProvider, string> connection-string resolver, and the modular-server example demonstrates tenant-specific management and runtime connection strings. So a database-per-tenant design is viable, but the bridge from ASP.NET Zero's tenant context to Elsa's tenant context, the per-tenant migrations/provisioning, and the background/scheduled-work tenant resolution are application responsibilities. They are not automatically supplied by an ASP.NET Zero integration package.

Use Elsa's EF Core persistence contexts and migration stream separately from your ABP application DbContext, even when both use the same physical SQL Server database. Separate databases per tenant are also appropriate when you need that isolation; test tenant resolution for HTTP requests and background work before production.

Relevant Elsa sources for 3.7.1:

• Supported target frameworks include .NET 9.
• SQL Server persistence configuration exposes the service-provider connection-string resolver.
• Tenant-specific persistence example shows separate management and runtime database settings.

Related context: Elsa discussion #5214 and ASP.NET Zero's current Elsa v3 guidance. If you pursue the first path and encounter a startup failure, please include the smallest host setup plus the resolved Elsa/ABP/Castle package versions; that will let us separate configuration problems from a container incompatibility.