SqlOrchestrationService is not visible when referencing Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer

[mikegoatly]

I'm working on migrating a .NET 6 function application from using the in-proc to isolated model of hosting.

The deployed version of the application does not run with DDL permissions to the database, so cannot run the migrations itself on start-up. What we have historically done is add a CI/CD deployment step that applies any outstanding migrations, just prior to deploying the application:

await new SqlOrchestrationService(new SqlOrchestrationServiceSettings(connectionString))
    .CreateAsync();

This works fine when using a reference to Microsoft.DurableTask.SqlServer.AzureFunctions, however when I switch to Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer, the DurableTask namespace and associated types are no longer resolvable. Both versions of the assembly are the same version (1.2.1):

It's possible I might be doing something wrong here, but I'm seeing minor differences in the schemas generated between the two, so I'd really like to make sure I'm using the correct SqlOrchestrationService to configure the schema.

Curiously, when I look at the assembly in the nuget package using ILSpy, I don't see any types in it, so I have no idea how the migration code is actually executed when I allow it to configure the schema on my local machine (which it can do successfully!)

[cgillum]

Hi @mikegoatly. The reason you're not seeing the DurableTask types anymore is because Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer doesn't have a direct dependency on the DurableTask assemblies. In fact, it doesn't define any types at all, which it seems you already noticed. Think of the "Worker" nuget packages as proxies telling what the Functions host needs to load without putting any dependencies into your actual app code.

To get your scenario working again, you should add a reference to Microsoft.DurableTask.SqlServer directly (not the AzureFunctions version, but that might still work).

I'm seeing minor differences in the schemas generated between the two

Ah, looks like this is a bug is the Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer package because it's referencing an older version of the Microsoft.DurableTask.SqlServer.Functions dependency (here).

The safe thing for you to do in this case is to specifically reference the latest v1.1.x release (not the v1.2.x release) of Microsoft.DurableTask.SqlServer in your project. This will ensure that both the runtime and your custom migration logic are using the same schema version. It may not be strictly necessary since the 1.2.0 schema should be backwards compatible with the 1.1.x schema, but it might be a good idea just to be safe.

I'll need to publish a fix to Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer to reference the 1.2.x version of Microsoft.DurableTask.SqlServer.Functions. Moving forward, for your migration code, make sure to keep these two version numbers in sync. Once this bug is fixed, that will ensure that you're always using the correct database schema.