agentleFS
GitHubKnown publishergithub/awesome-copilot/skills/logicapps-custom-code-net10-migration/SKILL.md

logicapps-custom-code-net10-migration

Skill41k starsChanged 21 days agoMITView on GitHub

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.

Trending

More talk lately.about the whole repository

Dec 2025: 10 mentionsJan 2026: 4 mentionsFeb 2026: 7 mentionsMar 2026: 12 mentionsApr 2026: 6 mentionsMay 2026: 2 mentionsJun 2026: 2 mentionsJul 2026: 2 mentionsAug 2026: 5 mentionsSep 2026: 9 mentionsOct 2026: 5 mentionsNov 2026: 1 mention
Dec 2025Jun 2026Nov 2026
Mentions a month of the github/awesome-copilot repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about github/awesome-copilot

The biggest 5 of 90 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 90

Talked about on Bluesky, GitHub, YouTube, Hacker News and the web (90 times).

On Bluesky · 41

36 more on Bluesky

On GitHub · 34

29 more on GitHub

On YouTube · 5

On the web · 5

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 5 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the migration procedure before editing.

    line 9
  2. Very specific:

    Read repository instructions and affected configuration, including dirty changes, inherited build/package/SDK settings, workspace and tool …

    line 17
  3. Distinctive:

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

    line 20
  4. Very specific:

    Use --project "<csproj path>" to select among multiple custom-code projects.

    line 26
  5. Very specific:

    Default edits cover framework/SDK/publication/runtime alignment, not reference dependency parity.

    line 30
  6. Very specific:

    Use --integrated-debug only when coordinated launching is requested/needed.

    line 32
  7. Very specific:

    If the helper refuses central/conditional/imported configuration, newer unreviewed SDK targets, or an unfamiliar debugger/layout, do not …

    line 37
  8. Very specific:

    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 …

    line 50
  9. Distinctive:

    Only upgrade the custom-code library.

    line 65
  10. Distinctive:

    Do not add sample-only HTTP, telemetry or framework references.

    line 68
  11. Very specific:

    Do not introduce Program.cs or an executable worker host.

    line 69
  12. Distinctive:

    No C# rewrites, SDK installation, restore, host start, Azure mutation or persistent secret backups inside the configuration helper.

    line 71
  13. Very specific:

    Do not silently downgrade packages, rewrite shared package management, suppress restore/build errors, copy .NET 10 DLLs to net472, or …

    line 73

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Logic Apps custom code .NET 10 migration

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.