← Live! 360 Orlando 2026 resources

Wed Nov 18 · AIW04

Claude Code for .NET Developers: Agentic Coding in the Enterprise

Everything from the session in one place. Each section is a scannable guide; the code blocks are copy-ready.

01

Setup guide: Claude Code on Windows

Two paths. Pick by the stack, not by preference. Install commands and requirements change. When in doubt, the official setup docs win over this page.

PowerShell

The .NET stack: ASP.NET Core, Blazor, MAUI, SQL Server.

  1. 1.
    Install. Run in PowerShell. No admin rights needed.
    PowerShell
    irm https://claude.ai/install.ps1 | iex
  2. 2.
    Optional: Git for Windows. With it, Claude Code runs shell commands through Git Bash; without it, through PowerShell. Either works.
  3. 3.
    Open a new terminal and check.
    PowerShell
    claude --version
claude doctor
  4. 4.
    First run. Start it from the solution root, the folder with the .sln.
    PowerShell
    cd C:\src\OrderDesk
claude
  5. 5.
    Authenticate. On first run, choose to sign in with your Claude account and complete it in the browser with your Pro or Max subscription. Use /status to confirm the account and /login to switch. Auth docs.
  6. 6.
    Inside your IDE. Visual Studio: View → Terminal (Developer PowerShell), then run claude. VS Code: Terminal → New Terminal, then run claude, or use the VS Code extension.

WSL

React, Node, and Linux-first tooling.

  1. 1.
    Install WSL if you don't have it (PowerShell as admin, then reboot and open your Linux distro).
    PowerShell (admin)
    wsl --install
  2. 2.
    Install Claude Code inside WSL.
    bash
    curl -fsSL https://claude.ai/install.sh | bash
  3. 3.
    Keep repos on the Linux side (~/src), not under /mnt/c. File access and watchers are much faster there.
  4. 4.
    Check and first run.
    bash
    claude --version
claude doctor
cd ~/src/orderdesk-ui
claude
  5. 5.
    Authenticate. Same as PowerShell: sign in with your Claude Pro or Max account. If the browser doesn't open on its own, copy the URL it prints. WSL needs its own sign-in.
  6. 6.
    Inside your IDE. From the repo in WSL, run code . to open VS Code connected to WSL. Its integrated terminal is then a Linux shell, so just run claude.

Two gotchas

Agent sessions can't see across PowerShell and WSL.

Each side has its own install, sign-in, settings, and session history. A session started in PowerShell won't show up in /resume on WSL, and the reverse is true too. Pick one side per repo and stay there.

Give every project its own port before you start.

With several agents running, two apps on 5000 or 3000 means one agent kills the other's server and "fixes" the wrong thing. Set the ports in launchSettings.json or your dev-server config, and write them into CLAUDE.md.

02

Repo order sheet

The order that works for a new project. Each step sets up the one after it.

  1. 1.
    Create the folders. Claude Code treats the folder you launch it in as the project, so set up the structure first.
  2. 2.
    git init and make a first commit. Every change the agent makes is then a diff against a clean baseline that you can review or roll back.
  3. 3.
    Open Claude Code in the repo root. Starting at the root lets it see the whole solution, and its project files land in the right place.
  4. 4.
    Run /init. It drafts CLAUDE.md from what is actually in the repo, not from what you remember is there.
  5. 5.
    Review and edit CLAUDE.md. /init guesses; you know the rules. Anything wrong here is wrong in every session.
  6. 6.
    Set permissions. Decide what runs without asking and what is never allowed before the agent touches a file.
  7. 7.
    Give it a first task. Start small and checkable, so you learn the build-and-test loop before you trust it with something big.

Example permissions in .claude/settings.json, committed so the whole team shares them. Use /permissions to view and edit them in a session. The rule syntax is in the settings docs.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(dotnet build *)",
      "Bash(dotnet test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(dotnet ef database update *)",
      "Read(./secrets/**)",
      "Read(./**/appsettings.Production.json)"
    ]
  }
}
03

CLAUDE.md starter

A starting point for an ASP.NET Core / Blazor solution. Replace the names, paths, and ports with your own. Keep it short: Claude reads it at the start of every session. How CLAUDE.md is loaded.

CLAUDE.md
# CLAUDE.md

## Solution overview
- Solution: OrderDesk.sln
- Projects:
  - src/OrderDesk.Web        — Blazor Web App (UI)
  - src/OrderDesk.Api        — ASP.NET Core Web API
  - src/OrderDesk.Core       — domain + services (no framework references)
  - src/OrderDesk.Data       — EF Core DbContext, entities, migrations
  - tests/OrderDesk.Tests    — xUnit unit + integration tests
- Local ports: Web https://localhost:5101, Api https://localhost:5102
  (set in launchSettings.json — do not change them)

## Build & test commands
- Restore:      dotnet restore
- Build:        dotnet build OrderDesk.sln
- Test (all):   dotnet test
- Test (one):   dotnet test --filter "FullyQualifiedName~OrderServiceTests"
- Format check: dotnet format --verify-no-changes
- Run web:      dotnet run --project src/OrderDesk.Web

## Conventions
- Target framework and language version come from Directory.Build.props.
- Nullable reference types are on; fix warnings, don't suppress them.
- async all the way down; every async method takes a CancellationToken.
- Dependency injection via constructor; register services in Program.cs.
- Blazor: one component per file; code-behind (.razor.cs) once a
  component's @code block passes ~30 lines.
- Data access goes through OrderDesk.Data; no DbContext in components.
- Logging via ILogger<T> with structured message templates — no string
  interpolation in log calls.
- Tests: Arrange / Act / Assert, one behavior per test, named
  Method_Scenario_ExpectedResult.

## Definition of done
A task is done only when all of these are true:
1. dotnet build has zero errors and no new warnings.
2. dotnet test passes — all tests, not just the new ones.
3. New behavior has at least one test that fails without the change.
4. dotnet format --verify-no-changes passes.
5. You have listed every file you changed and why.

## Never
- Never delete, skip, or weaken a test to make the build pass. If a test
  looks wrong, stop and ask.
- Never create, edit, or delete EF Core migrations, or run
  dotnet ef database update.
- Never touch authentication or authorization code (Program.cs auth
  setup, [Authorize] attributes, Identity configuration) without asking.
- Never read, write, or print secrets: user-secrets, connection strings,
  appsettings.Production.json, .env files, keys.
- Never commit, push, or create branches. Leave changes uncommitted for
  review.
04

Weekly full-repo audit

A recurring security audit and code review of the whole repo. It's read-only, it runs every week, and a human triages the findings.

1. Save the prompt as a skill

Commit this as .claude/skills/weekly-audit/SKILL.md. It then runs as /weekly-audit for everyone on the team. Skills docs.

.claude/skills/weekly-audit/SKILL.md
---
description: Weekly full-repo security audit and code review. Read-only.
---

Audit this entire repository. Do not change any files.

Security — look for:
- Secrets or connection strings committed anywhere, including history
  hints such as removed config files referenced in docs.
- Missing or inconsistent [Authorize] / authorization policies on
  controllers, minimal API endpoints, and Blazor pages.
- SQL built by string concatenation; raw SQL without parameters.
- Unvalidated input reaching file paths, redirects, or process starts.
- Outdated or vulnerable packages (run: dotnet list package --vulnerable).
- CORS, cookie, and HTTPS settings that are looser than they need to be.

Code review — look for:
- Async misuse: .Result / .Wait(), async void, missing CancellationToken.
- Swallowed exceptions and catch blocks that only log.
- Dead code, duplicated logic, and classes doing too many jobs.
- Tests that assert nothing meaningful, or code paths with no tests.

Report format — a single markdown table, most severe first:
| Severity (Critical/High/Medium/Low) | File:line | Finding | Why it matters | Suggested fix |

Then list anything you could not check and why.

Known and accepted (do not report these again):
- (add items here as you triage them)

2. Schedule it

Manual Friday routine

  • Pull the latest main.
  • Run /weekly-audit in plan mode so nothing gets changed (commands below).
  • Save the report to audits/ with the date in the filename.
  • Triage it before you log off (step 3).

Azure DevOps scheduled pipeline

Run the same skill headless on a weekly cron trigger and publish the report as a pipeline artifact. Pipeline setup, credentials, and guardrails are in the Thursday session.

Agentic DevOps resources →
PowerShell
# Interactive: start in the repo root, press Shift+Tab until
# plan mode is on, then run the skill
claude
> /weekly-audit

# Or headless, saving the report to a dated file. Edits aren't
# pre-approved, so headless mode can't make them.
claude -p "/weekly-audit" --allowedTools "Bash(dotnet list package *)" |
  Out-File "audits\audit-$(Get-Date -Format yyyy-MM-dd).md"

Headless flags: headless docs.

3. What to do with the findings

  • Critical / High: open a work item today. Fix it this week.
  • Medium: add it to the backlog, tagged audit, so you can see the trend.
  • Low / noise: add it to the prompt's "Known and accepted" list so it stops coming back.
  • One finding = one task = one reviewed diff. Never let the audit run fix its own findings.
  • Compare to last week. A finding that keeps coming back is a CLAUDE.md rule you haven't written yet.
05

Prompting patterns

The three patterns from the talk, each one copy-ready.

1. "Ask me five questions"

Make it ask before it builds. The questions show you what it would otherwise have guessed.

prompt
I want to add CSV export to the Orders grid in OrderDesk.Web.
Users should be able to export what they're currently looking at,
filters included.

Before you write any code, ask me five questions about what I'm about
to build. Wait for my answers before planning anything.

2. Numbered tasks (Task 1 / Task 2 / Task 3)

Split the work into steps that each have a checkpoint and an explicit place to stop.

prompt
Task 1: Read OrderService and its tests. Summarize how order totals are
calculated today. Don't change anything.

Task 2: Write failing tests for the discount rules below. Run them and
show me they fail.
  - 10% off orders over $500
  - Discounts never stack

Task 3: Implement the rules until every test passes. Stop after Task 3
and list every file you changed.

3. Behavior, not implementation

Describe what the user sees and how you'll know it's done. Let it choose the code.

prompt
Behavior: When a user tries to submit an order with a ship date in the
past, the form should block submission and show "Ship date must be today
or later" under the date field. The API should reject the same request
with a 400 and the same message, so the rule holds even if the UI is
bypassed.

Done when: there are tests for both the UI validation and the API
response, and the full test suite passes.
06

Demo prompts

The exact prompts from the three live demos.

Demo 1: Fresh Blazor app

Coming after the session

The exact prompt from Demo 1: Fresh Blazor app will be posted here.

Demo 2: Legacy investigation

Coming after the session

The exact prompt from Demo 2: Legacy investigation will be posted here.

Demo 3: Five questions on a real feature

Coming after the session

The exact prompt from Demo 3: Five questions on a real feature will be posted here.

07

Slides

Coming after the session

The slide deck (PDF) will be posted here after the session.

How to reach me