Skip to main content

Logicapps Custom Code Net10 Migration

Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project/package configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.

Install with the GitHub CLI
gh skills install github/awesome-copilot logicapps-custom-code-net10-migration
Files in this skill
SKILL.md · 5 KB

Read the migration procedure before editing. Resolve bundled files relative to this skill, not the target repository. Python 3.11+ is required only for the helper; do not install dependencies or start services merely by activating this skill.

Procedure

  1. Establish the solution root, custom-code .csproj, and Logic Apps host.json root. Infer existing names/layout; ask only about ambiguous project selection or effects. Read repository instructions and affected configuration, including dirty changes, inherited build/package/SDK settings, workspace and tool paths. Do not inspect C# contents unless separately authorized to diagnose a build failure.

  2. Run the bundled helper in its default dry-run mode:

    python "<skill root>\scripts\migrate.py" --root "<solution root>"

    Use --project "<csproj path>" to select among multiple custom-code projects. The helper resolves LogicAppFolderToPublish; it does not require Functions or LogicApps folder names. Read all reported blockers/warnings. It prints no settings values and writes nothing in dry-run mode. Default edits cover framework/SDK/publication/runtime alignment, not reference dependency parity. Preserve absent Worker packages and existing debugger configuration. Use --integrated-debug only when coordinated launching is requested/needed.

  3. For a requested migration, apply the reviewed plan with the same coordinates and --apply. Do not apply for a comparison/plan-only request. The helper guards changed files and rolls back its own completed writes on failure; it is not an atomic multi-file transaction or a persistent backup. Preserve unrelated user edits.

  4. If the helper refuses central/conditional/imported configuration, newer unreviewed SDK targets, or an unfamiliar debugger/layout, do not bypass the guard. Read the owning configuration, resolve scope with the user when shared projects are affected, and make targeted agent edits using repository tools. Never claim universal helper coverage. Repeat the dry run to check idempotency for supported layouts.

  5. Validate with the repository's build/analyzers and approved package source. Use the exact SDK selected by VS Code, not just PATH. Verify assembly/dependency publication and generated local-function metadata. Review custom build/publication hooks and obtain separate authorization for any deployment/network effects before building; a disposable copy does not neutralize those hooks. Obtain permission for trigger/connector effects before host startup or workflow execution. Follow the installed Logic Apps runtime skill/procedure when available; otherwise perform ownership-aware VS Code launch and verify actual execution, not just debugger attachment. If the SDK's directory scan fails on a clean build, rerun the helper dry run/apply with --ensure-output-directory, then repeat the failed build. Do not introduce the guard as a universal framework requirement. Resolve genuine missing-dependency errors individually; do not add Worker/HTTP/telemetry packages just to match a sample.

  6. Report changed configuration, dry-run/apply/tests, and separate states: configuration migrated, build verified, local-function execution verified. State blockers plainly. Always report the later deployment prerequisite: Azure app settings must carry LOGIC_APPS_CUSTOMCODE_DOTNETVERSION=net10.0 and FUNCTIONS_INPROC_NET8_ENABLED=1. Deployment through the Logic Apps extension in VS Code copies these settings; pipelines must explicitly include them. A local settings file alone does not configure Azure. Do not deploy, change Azure app settings, or assert cloud/production support.

Invariants

  • Only upgrade the custom-code library; preserve host .NET 8 configuration.
  • Preserve names, workflows, connections, authentication, storage, unrelated dependencies, workspace/task conventions, comments and secret exclusions.
  • Do not add sample-only HTTP, telemetry or framework references.
  • Do not introduce Program.cs or an executable worker host. Library Main() is not automatically executed; source preservation is intent, not verified API compatibility.
  • No C# rewrites, SDK installation, restore, host start, Azure mutation or persistent secret backups inside the configuration helper.
  • Do not silently downgrade packages, rewrite shared package management, suppress restore/build errors, copy .NET 10 DLLs to net472, or manufacture passing checks.

Installation and test commands are in README.md. Bundled resources include the migration helper, regression tests, and MIT license.