dotnet deploy optimize skill by jeffschwMSFT · Pull Request #11 · dotnet/skills

jeffschwMSFT · 2026-02-12T19:55:18Z

Proposing a skill for offering recommendation on how to optimize a .NET Core application during publish

Comprehensive deployment optimization skill for .NET 8+ apps covering: - Publish modes (framework-dependent, self-contained, single-file, R2R, Native AOT) - Publish setting compatibility matrix - Trimming and tree-shaking - Docker image optimization - CI/CD pipeline tuning - Configuration and secrets management - Health checks and readiness probes

Critical fixes: - Add missing ReadyToRun + SelfContained=false conflict row - Add Worker Service-specific health check guidance (Kestrel, publisher, TCP) - Broaden secrets check to all appsettings*.json files Moderate fixes: - Add dotnet publish CLI command example alongside XML properties - Short-circuit Step 3 (trimming) when AOT is chosen - Tighten Worker Service detection to require BackgroundService/IHostedService - Add AOT vs JIT tiered compilation trade-off for long-running workloads - Add skip guard on Step 7 for apps with no config files

…-optimize

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Users ask about fast startup and small binaries rather than technical terms like Native AOT and trimming. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Adds a new .NET deployment optimization skill intended to help users choose appropriate dotnet publish settings (trimming/AOT/single-file), plus an eval suite to validate recommendations across common app types.

Changes:

Introduces dotnet-deploy-optimize skill documentation covering publish modes, trimming, Native AOT, Docker, CI/CD, config, and health checks.
Adds dotnet-deploy-optimize evaluation scenarios for a Web API, conflicting publish properties, and a Worker Service.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
src/dotnet/skills/dotnet-deploy-optimize/SKILL.md	New skill content describing a workflow for deployment/publish optimization and operational readiness.
src/dotnet/tests/dotnet-deploy-optimize/eval.yaml	New eval scenarios to validate the skill’s recommendations across project types and settings.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-20T18:42:41Z

+1. Option A — Add a minimal Kestrel endpoint for health checks:
+
+```csharp
+builder.Services.AddHealthChecks()
+    .AddCheck("self", () => HealthCheckResult.Healthy());
+
+builder.WebHost.UseKestrel(o => o.ListenAnyIP(8080));
+var app = builder.Build();
+app.MapHealthChecks("/healthz");
+```


The Worker Service health-check snippet uses builder.WebHost.UseKestrel(...), builder.Build(), and app.MapHealthChecks(...) without showing where builder comes from. As written, it won’t compile in a typical Worker Service template (Host.CreateDefaultBuilder / HostApplicationBuilder) and may confuse users. Suggest providing a complete, self-contained example that matches the Worker template (or explicitly state this option switches to a WebApplicationBuilder-based minimal host alongside the worker).

Copilot · 2026-02-20T18:42:41Z

+                <PublishAot>true</PublishAot>
+                <PublishSingleFile>true</PublishSingleFile>
+                <ReadyToRun>true</ReadyToRun>
+                <SelfContained>false</SelfContained>
+              </PropertyGroup>


The eval fixture uses <ReadyToRun>true</ReadyToRun>, but the publish property name is PublishReadyToRun. Using the wrong property here makes the scenario less realistic and can cause the agent to learn/emit an invalid setting. Recommend switching the fixture (and rubric wording) to PublishReadyToRun.

Copilot · 2026-02-20T18:42:42Z

+            app.Run();
+    assertions:
+      - type: "output_contains"
+        value: "conflict"


This scenario’s assertion only checks for the literal word "conflict", which doesn’t strongly validate the expected behavior (and may fail if the recommendation uses synonyms like "incompatible"). Consider asserting for the specific properties involved (e.g., PublishAot, PublishSingleFile, PublishReadyToRun, SelfContained) or using an output_matches regex that requires mentioning at least two of them.

Suggested change

value: "conflict"

value: "PublishAot"

- type: "output_contains"

value: "PublishSingleFile"

- type: "output_contains"

value: "ReadyToRun"

- type: "output_contains"

value: "SelfContained"

Copilot · 2026-02-20T18:42:42Z

+            var builder = Host.CreateDefaultBuilder(args);
+            builder.ConfigureServices(services =>
+            {
+                services.AddHostedService<Worker>();
+            });
+            var host = builder.Build();


In the Worker Service fixture, Host.CreateDefaultBuilder(args) returns an IHostBuilder where ConfigureServices typically takes (HostBuilderContext, IServiceCollection) rather than a single services parameter. As written, the snippet won’t compile; consider adjusting the fixture to a valid Worker template so the scenario reflects real-world code.

Suggested change

var builder = Host.CreateDefaultBuilder(args);

builder.ConfigureServices(services =>

{

services.AddHostedService<Worker>();

});

var host = builder.Build();

using Microsoft.Extensions.Hosting;

var host = Host.CreateDefaultBuilder(args)

.ConfigureServices((context, services) =>

{

services.AddHostedService<Worker>();

})

.Build();

Copilot · 2026-02-20T18:42:42Z

+
+1. Read the project file(s) and identify the target framework, output type, and any existing publish settings.
+2. Check for a `Properties/launchSettings.json`, `appsettings.json`, and `appsettings.*.json` files.
+3. Note any existing `PublishTrimmed`, `PublishAot`, `PublishSingleFile`, `ReadyToRun`, or `SelfContained` properties.


The skill refers to the publish setting as ReadyToRun, but in .NET/MSBuild the publish property is PublishReadyToRun (see other skills in this repo). Using ReadyToRun here will mislead readers and the later compatibility matrix/rubric. Recommend renaming to PublishReadyToRun throughout (including the eval fixtures).

Suggested change

3. Note any existing `PublishTrimmed`, `PublishAot`, `PublishSingleFile`, `ReadyToRun`, or `SelfContained` properties.

3. Note any existing `PublishTrimmed`, `PublishAot`, `PublishSingleFile`, `PublishReadyToRun`, or `SelfContained` properties.

Copilot · 2026-02-20T18:42:43Z

+| Setting A | Setting B | Outcome | Explanation |
+|-----------|-----------|---------|-------------|
+| `PublishAot` | `PublishSingleFile` | **Conflict** | AOT produces a single native binary by default; `PublishSingleFile` is for IL-based apps and is ignored with AOT |
+| `PublishAot` | `ReadyToRun` | **Conflict** | ReadyToRun pre-compiles IL to native via crossgen; AOT replaces the IL pipeline entirely, making R2R meaningless |
+| `PublishAot` | `SelfContained=false` | **Conflict** | AOT output is always self-contained; setting `SelfContained` to false is contradictory and will cause a build error |


In the compatibility matrix, the outcome is marked Conflict but the explanation says the setting is "ignored"/"meaningless". That reads like a redundant/no-op combination rather than a hard conflict (build error). Consider changing the outcome wording (e.g., "Redundant/ignored") so the guidance is unambiguous.

Copilot · 2026-02-20T18:42:43Z

+   - Heavy use of `System.Reflection` and using string representations of types, strongly typed reflection is not problematic
+   - Dynamic assembly loading
+   - `System.Text.Json` source generators not configured
+   - COM interop
+   - Check trim-compatibility of dependencies, including from nuget


The trimming bullet is a run-on sentence and hard to parse ("Heavy use of ... , strongly typed reflection..."). Also, "nuget" should be capitalized as "NuGet" here (and again in the AOT section). Recommend rewriting this bullet into clearer sub-bullets and fixing capitalization.

Suggested change

- Heavy use of `System.Reflection` and using string representations of types, strongly typed reflection is not problematic

- Dynamic assembly loading

- `System.Text.Json` source generators not configured

- COM interop

- Check trim-compatibility of dependencies, including from nuget

- Reflection usage:

- Heavy use of `System.Reflection` APIs that rely on string-based type or member names (for example, `Type.GetType("Namespace.TypeName")`)

- Strongly typed reflection (such as `typeof`, `nameof`, or expression-based access) is generally trim-safe

- Dynamic assembly loading

- `System.Text.Json` source generators not configured

- COM interop

- Check trim-compatibility of dependencies, including from NuGet

The model already scores 5/5 on conflict detection without guidance. The compatibility table added ~300 tokens without improving results, and the skill was flagged as approaching the 'comprehensive' range where gains diminish. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- Add prominent warning against defaulting to AOT for long-running services; explain JIT tiered compilation and dynamic PGO benefits - Add workload lifetime decision point before recommending AOT - Reorder worker health check options from lightest to heaviest - Add trade-off callout for adding Kestrel to worker services - Present file-based and TCP probes as lighter alternatives Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AOT, R2R, and tiered JIT are orthogonal trade-offs (startup, binary size, dependencies, steady-state throughput). Present a comparison table so the user can choose based on what they value, rather than prescribing based on long-running vs short-lived. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jeffschwMSFT · 2026-02-21T19:02:21Z

well, this was my first attempt and I do not think it has the right fitness. but parts may be interesting

Skill	Scenario	Baseline	With Skill	Δ	Verdict
dotnet-deploy-optimize	Basic Web API publish optimization	4.0/5	3.0/5	-1.0	⚠️
dotnet-deploy-optimize	Detect conflicting publish settings	5.0/5	1.0/5	-4.0	❌
dotnet-deploy-optimize	Worker service deployment readiness	2.0/5	3.0/5	+1.0	✅

Note: "Detect conflicting publish settings" is marked ❌ because the with-skill agent timed out at 180s with zero output delivered to the user. It spent all its time in diagnostic investigation and build output analysis, never producing any findings or recommendations. The baseline completed successfully with a 5.0/5 score, making this a significant regression in both task completion (✓→✗) and quality.

jeffschwMSFT · 2026-02-25T15:53:28Z

the highest value of this proposed skill was the health check, which another proposed skill covers

…date+cleanup step Restore content lost when orchestrator was rewritten as pure dispatcher, plus add preventative guidance addressing the three regressions found in run 25504147640 (resolution dropped from 39%->17% vs run 25497220848). orchestrator (code-testing-generator.agent.md): - Step 1: reference unit-test-generation.prompt.md and pre-pipeline git stash - Step 4: implementer dispatch prompt now embeds test-strength rubric (concrete-value assertions, N>=3 collection inputs, full-equality, no toBeTruthy-only) and file-location rules - Step 8: restore Coverage Gap Iteration (re-research/plan/implement narrowed scope when rubric items remain uncovered) - Step 9 NEW: Validate-and-cleanup dispatch to code-testing-builder which has terminal/edit access. Removes .testagent/, runs git diff --name-only, reverts SUSPICIOUS files (env/cfg/toml/source-outside-test). Addresses 6/12 manifest_fail cases caused by .testagent/ leaking into the patch. - Rules: add dotnet#10 (cleanup mandatory) and dotnet#11 (test strength belongs in implementer prompt, not tester post-hoc check) implementer (code-testing-implementer.agent.md): - Step 4a NEW: Test strength requirements with concrete bad/good examples, reserved-name keys for property iteratees, mutation-resistance check - Step 4b NEW: File-location and side-effect rules with naming decision tree - Rules: add dotnet#6 (test strength non-negotiable) and dotnet#7 (stay inside test dirs) planner (code-testing-planner.agent.md): - Step 4: Add allowed/forbidden file targets, naming decision tree, and scenario depth requirement (N>=3 elements with concrete expected values) Diagnosis from run 25504147640: - 10/41 patches contained .testagent/research.md or plan.md (no cleanup) - mutation_fail jumped from 18 to 24 (single-element collection inputs, type-only assertions allowed weaker tests through) - app-2ad2720a modified tests/test.env DB port (no rule against config edits) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…otnet - Startup-style config, NHibernate/MassTransit/Serilog notes

jeffschwMSFT added 2 commits February 12, 2026 11:44

review feedback

7777dcc

jeffschwMSFT mentioned this pull request Feb 12, 2026

Skill idea: Trimming & AOT Readiness #8

Open

jeffschwMSFT and others added 4 commits February 12, 2026 13:43

add eval.yaml for validation and comparision

60bdae5

Merge remote-tracking branch 'upstream/main' into skill/dotnet-deploy…

cd40829

…-optimize

Move dotnet-deploy-optimize skill to src/dotnet directory structure

361295f

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings February 20, 2026 18:37

Copilot started reviewing on behalf of jeffschwMSFT February 20, 2026 18:38 View session

Rewrite eval prompts to use natural language

3e011dd

Users ask about fast startup and small binaries rather than technical terms like Native AOT and trimming. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI reviewed Feb 20, 2026

View reviewed changes

jeffschwMSFT and others added 3 commits February 20, 2026 12:57

jeffschwMSFT marked this pull request as draft February 21, 2026 19:03

jeffschwMSFT closed this Feb 25, 2026

github-actions Bot mentioned this pull request Jun 3, 2026

fix(dotnet): add Claude Code-shaped .lsp.json so LSP loads in Claude Code #598

Merged

3 tasks

moesac0970 pushed a commit to moesac0970/skills that referenced this pull request Jul 4, 2026

task(dotnet#11): tailor dotnet-aspnetcore/configuring-opentelemetry-d…

074e995

…otnet - Startup-style config, NHibernate/MassTransit/Serilog notes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

dotnet deploy optimize skill - #11

dotnet deploy optimize skill#11
jeffschwMSFT wants to merge 10 commits into
dotnet:mainfrom
jeffschwMSFT:skill/dotnet-deploy-optimize

jeffschwMSFT commented Feb 12, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

Copilot AI Feb 20, 2026

Uh oh!

jeffschwMSFT commented Feb 21, 2026

Uh oh!

jeffschwMSFT commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	3. Note any existing `PublishTrimmed`, `PublishAot`, `PublishSingleFile`, `ReadyToRun`, or `SelfContained` properties.
	3. Note any existing `PublishTrimmed`, `PublishAot`, `PublishSingleFile`, `PublishReadyToRun`, or `SelfContained` properties.

Uh oh!

Conversation

jeffschwMSFT commented Feb 12, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

jeffschwMSFT commented Feb 21, 2026

Uh oh!

jeffschwMSFT commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants