What the Logic App needs in Azure
| Setting | Value |
|---|---|
| Plan | Workflow Standard (WS1 or larger), Windows or Linux |
AzureFunctionsJobHost__extensionBundle__* | Delete both: the project is NuGet-based |
FUNCTIONS_WORKER_RUNTIME | dotnet |
FUNCTIONS_INPROC_NET8_ENABLED | 1 |
LAMBOGENIUS_LICENSE | Your license token, as a Key Vault reference |
| Platform | .NET v8.0, 64-bit worker process |
XsltCompose__FunctionRegistryPath | When maps call Functions |
A Logic App created in the portal or with az logicapp create starts as an extension-bundle app; change those settings before you deploy.
Bicep and scripts
The connector's distribution includes a Bicep template that creates the plan, the Logic App with a managed identity, the sample Function, a Key Vault holding the Function key (copied inside Azure Resource Manager, never printed), and monitoring. A deploy script runs it and zip-deploys both apps:
$env:AZURE_CONFIG_DIR = "$HOME/.azure-dev"; az login --tenant <tenant-id>
az group create -n rg-xslt-dev -l canadacentral
az deployment group create -g rg-xslt-dev -f infra/main.bicep -p infra/main.bicepparam -p licenseToken=<token>
# then zip-deploy the published Logic App (dotnet publish -c Release)
az logicapp deployment source config-zip -n <logic-app> -g rg-xslt-dev --src logic-app.zipAfter deployment
- The provider is registered: the runtime's
operationGroupslist includeslamboXsltCompose. - The worker starts: the first call after a deployment or restart takes a few seconds (worker start and compile); later calls take milliseconds.
- Publish output includes
xslt-worker/withLambogenius.XsltCompose.Worker.dll. Deploy the published folder, not the build folder. - Function keys belong in Key Vault references; managed identity needs App Service Authentication on the Function app that allows the Logic App's identity.