[Bryan Bennett (bjbennet)]

Summary

• add a headless .NET tool that publishes SDK-based code-first Logic App projects and assembles a ZIP-deployable artifact
• stage Logic App assets at the package root and worker output under lib/codeful
• normalize and validate worker.config.json, apply built-in and .funcignore exclusions, and produce deterministic ZIP output
• reject traditional in-process Logic App projects with an actionable error
• add focused tests, solution wiring, CI test execution, NuGet tool packaging, and usage documentation

Validation

• full Release solution build succeeds with zero warnings and errors
• packager test suite passes: 8 tests
• NuGet tool package builds successfully
• representative project-referenced SDK worker packages successfully into a 35-file ZIP
• real Logic App Standard ZIP deployment completed successfully and the SDK workflow was indexed after removing an incompatible custom extension-bundle override
• workflow execution succeeded after configuring the managed connection and refreshing the workflow

Related to serverless-paas-balam/logic-apps-central#1045.

[Bryan Bennett (bjbennet)]

Andrew Eldridge (@andrew-eldridge) Agreed that the user-facing command should live in the Logic Apps CLI. The current SDK implementation is a validated prototype; my proposed split is for the SDK-specific packaging engine/contract tests to remain reusable here, while the CLI owns the public command, distribution, telemetry, and release lifecycle. The command must remain installable on headless CI agents without VS Code. Could you point me to the intended CLI repository and extension/package boundary? I could not identify a standalone Standard Logic Apps CLI in the accessible Azure repositories, so I want to confirm the target before restructuring this PR.

[Bryan Bennett (bjbennet)]

Follow-up: the intended command family is in Azure/azure-cli on its dev branch, under src/azure-cli/azure/cli/command_modules/appservice. �z logicapp deployment source config-zip already owns the upload step. I propose adding �z logicapp package --project --output there as a thin Python wrapper over an SDK-provided MSBuild packaging target. Keeping the package contract in MSBuild/.NET avoids reimplementing .funcignore handling, worker.config normalization, validation, and deterministic ZIP behavior in Azure CLI Python. I am setting up the cross-repo implementation with that boundary unless you see a different preferred command shape.

[Bryan Bennett (bjbennet)]

Update after reviewing Azure/azure-cli-extensions#10467: that preview extension already owns �z logicapp deployment package, including deterministic ZIP/manifest generation, .funcignore, secret scanning, and general Logic Apps Standard packaging. The non-duplicating follow-up is therefore to extend that existing command with SDK/codeful worker publish/staging support rather than add a separate Azure CLI command or distribute this repository's .NET tool. The follow-up implementation is committed at bjbennet/azure-cli-extensions@12c0e4c on branch �rbenn-microsoft-sdk-codeful-packaging, based exactly on #10467 head 61f785ec39fd2adedf75b080daebb69fdfbe5618. It will be submitted upstream after #10467 merges or its base becomes targetable. This SDK PR remains a validated behavioral prototype and should stay draft pending a decision on whether any reusable SDK-owned MSBuild/library surface is still needed.

[Bryan Bennett (bjbennet)]

Superseded by Azure/azure-cli-extensions#10516.

During validation we determined that packaging belongs in the Logic Apps Azure CLI extension. The follow-up extends the existing az logicapp deployment package command with SDK/codeful support instead of introducing a separate .NET tool and distribution model. This PR served as the behavioral prototype and informed the CLI implementation, but its code should not be merged.