DEV Community: Mo

8 Filler Phrases That Quietly Weaken Your CV (And the Stronger Lines to Replace Them)

Mo — Tue, 01 Sep 2026 09:27:59 +0000

TL;DR — Most CVs are not weak because the person is weak. They are weak because filler phrases hide real work behind vague words. Below are eight common phrases, why each one costs you visibility, and a stronger line to use instead. At the end, I show how we built this thinking into CVSet, the CV scoring and tailoring tool I design.

I have read a lot of CVs while building CVSet. The pattern is almost always the same: a strong engineer writes "responsible for maintaining internal systems" when what they actually did was rebuild a payment integration that six teams depend on.

The facts were there. The wording buried them.

That gap is the whole reason CVSet exists. Not to invent a better candidate — to make the real one visible.

Why filler creeps in

Filler is not laziness. It comes from three habits:

Job-description language. You copy the phrasing from the advert you originally applied to.
Modesty. "Helped with" feels safer than "led", especially if the work was shared.
Speed. You update your CV at 11 pm the night before a deadline.

The fix is not to exaggerate. It is to say the same thing with the specifics still attached.

The 8 phrases

1. "Responsible for…"

This describes a job title, not a contribution. Anyone in that seat was responsible for it.

❌ Responsible for the company's CI/CD pipeline.

✅ Rebuilt the CI/CD pipeline, cutting deployment time by 10%.

If you do not have a number, use scope instead: "Rebuilt the CI/CD pipeline used by four engineering teams." Scope is still evidence.

2. "Worked on…"

"Worked on" hides your role completely. Did you design it, build it, review it, or attend the meetings?

❌ Worked on a microservices migration.

✅ Migrated three monolith modules to independent .NET services.

Pick the verb that matches what you actually did. Built, designed, migrated, tested, documented — each one tells a different story, and all of them beat "worked on".

3. "Helped with…"

Shared work is normal. But "helped" makes you sound optional.

❌ Helped with the authentication rewrite.

✅ Built the token refresh and session handling for the authentication rewrite.

You are not claiming the whole project. You are naming your part of it. That is more honest, not less.

4. "Team player"

Every candidate says this. It is a claim with no evidence behind it.

❌ Strong team player with excellent collaboration skills.

✅ Ran weekly code reviews for a team of six and onboarded two junior developers.

The second line proves collaboration without using the word.

5. "Results-driven" / "Results-oriented"

If you have results, show them. If you do not, the adjective will not cover the gap.

❌ Results-driven engineer focused on delivery.

✅ Reduced average API response time from 800ms to 210ms.

The rule: replace the adjective with the result it is describing.

6. "Excellent communication skills"

A recruiter cannot verify this. They can verify what you communicated, and to whom.

❌ Excellent written and verbal communication skills.

✅ Wrote the API documentation used by three external integration partners.

Audience plus artefact beats adjective every time.

7. "Passionate about technology"

Passion is not a qualification, and this line takes space near the top of your CV where space is expensive.

❌ Passionate about clean code and emerging technologies.

✅ Maintain an open-source .NET library with 400+ downloads.

If your passion produced something, name the something. If it did not, cut the line.

8. "Various" / "Multiple" / "A range of"

These words exist to avoid listing. But the list is the valuable part.

❌ Experience with various cloud technologies.

✅ Experience with Azure App Service, Azure Functions and Azure SQL.

This one also matters for ATS keyword matching. A scanner looking for "Terraform" will never match "various infrastructure tools".

The rule underneath all eight

Every rewrite above follows the same principle:

Same facts, better visibility.

Nothing was invented. No new skill appeared. No number was guessed. The work was always there — the wording just stopped hiding it.

This is the constraint we designed CVSet around, and it is non-negotiable in the product. The AI never adds a skill, a tool, or an achievement that is not already in your CV.

How CVSet applies this

Here is the flow, and what each step is actually for.

Step 1 — Analyse

Your CV is scored across nine dimensions, including Metrics & Impact, Clarity & Brevity, ATS Keywords and Expertise Presentation. Filler phrases usually show up as a low Metrics & Impact score, because vague verbs leave nothing to measure.

You also see the CV through four perspectives: Hiring Manager, Recruiter, Human Eye, and Algorithm. The same sentence can read fine to a human and be invisible to a parser.

That split view is the honest version of the filler problem. The left column is what your wording already proves. The right column is what it does not — and neither side is a guess, both come from your own CV against that specific job.

Step 2 — Optimise

Analysis becomes suggestions. Each one names the problem and the next step, so you are never told "improve this" without being told how.

Step 3 — Tailor

Here you paste a job description, and the CV is rewritten against it across five dimensions: Skills, Keywords, Language, Prioritisation, Quality.

Crucially, you accept or reject every change individually.

You can see the mechanism in that screenshot: the original text stays visible next to the suggestion, each change shows the score impact, and "Keep as is" is a first-class option. Prioritisation changes order only — no text is touched.

Step 4 — Skill Gap Analysis

This is the part I care most about. When the job asks for something your CV genuinely does not contain, we do not write it in.

Instead, it goes to your To-Learn List, with a reason and a concrete way to close it.

A gap is not a failure. It is the next thing to build.

What we got wrong first

Two honest lessons from building this.

Overlapping dimensions destroyed trust. In an early version, both Metrics and Completeness flagged the same missing number. Users saw one problem reported twice and assumed the scoring was padded. We fixed it with a single-owner rule: each dimension owns specific properties and has a deny-list. If a dimension does not own it, it does not mention it.

Silent changes feel worse than bad changes. Anything the tool does without asking reads as untrustworthy, even when the change is good. That is why nothing is applied until you accept it, and why we surface the original text next to every suggestion.

Score ceilings had to be honest. Not every CV can reach 100 on every dimension. Showing a ceiling you cannot reach is just a different kind of filler.

Try this in ten minutes

You do not need a tool to start. Open your CV and do this:

Search for the eight phrases above.
For each hit, ask: what did I actually do here?
Rewrite using a specific verb plus a number or a scope.
If you cannot find either, ask whether the line earns its space.

That is it. No new experience required.

Key Takeaways

Filler is a visibility problem, not a truth problem. Your work is already good enough; the wording is the bottleneck.
Replace adjectives with the evidence they describe. "Results-driven" becomes the actual result.
Use scope when you do not have a number. Team size, system count and user count are all real evidence.
Never invent to fill a gap. A missing skill belongs on your learning list, not in your experience section.
Vague words break ATS matching. "Various cloud tools" matches nothing a parser is searching for.
Same facts, better visibility is the only safe rewrite rule.

Over to you

Which filler phrase is still hiding in your CV right now? I would guess "responsible for" — it survives longer than the others because it sounds formal.

Next post, I want to go deeper on the ATS side: what a parser actually reads, and why formatting choices like columns and photos change the outcome more than people expect.

You can try the scoring at cvset.io.

What an ATS Actually Does With Your CV (And How to Stay Visible)

Mo — Tue, 01 Sep 2026 09:12:30 +0000

TL;DR — An Applicant Tracking System does three things: it parses your CV into structured data, ranks it against the job description, and filters what a recruiter sees first. Most CVs lose points at the parsing stage, before anyone reads a word. Fix the structure, keep the facts, and you stay visible. This post explains each stage, then shows how we built CVSet around it.

Most job seekers picture the ATS as a robot with an opinion. It reads your CV, decides you are not good enough, and deletes you.

That is not what happens. The ATS is closer to a filing cabinet with a search bar. It takes your document, tries to turn it into database rows, and hands the recruiter a searchable list. The damage happens when it cannot read your file properly, because a field it cannot fill is a field nobody can search.

I have spent the last year building a CV scoring product, and this stage broke more CVs than any writing problem we saw.

Stage 1: Parsing — the machine reads your file first

Before anything is scored, your PDF or DOCX is converted into text, then split into fields.

A parser is trying to fill a shape like this:

{
  "name": "...",
  "email": "...",
  "phone": "...",
  "experience": [
    {
      "title": "...",
      "company": "...",
      "start_date": "...",
      "end_date": "...",
      "bullets": ["..."]
    }
  ],
  "education": [],
  "skills": []
}

Every empty field is a search you will not appear in. If title is blank, you do not show up when a recruiter filters for "Product Designer".

Here is the part people miss. Text extraction follows the reading order stored in the file, not the visual order you see on screen. A two-column CV often comes out like this:

# What you see (two columns, side by side):
#   LEFT: Skills, Languages     RIGHT: Experience
#
# What the extractor returns:

Skills
Figma, Next.js, Azure
Languages
English, Persian
Experience
Senior Product Designer
CVSet · 2024 – Present

Readable enough for a human. But the parser now has to guess where the sidebar ends and the job history begins. Tables, text boxes and headers make this worse, because their content is often stored in a separate layer of the document.

What actually breaks parsing:

Contact details inside the page header or footer
Job titles and dates inside table cells
Icons used instead of labels (a phone glyph is not the word "Phone")
Dates written as images, or as ranges the parser cannot pattern-match
Scanned or exported-as-image PDFs with no text layer at all
Creative section names like "My Journey" instead of "Experience"

None of these are writing problems. They are file problems.

Stage 2: Ranking — keyword matching, not judgement

Once the fields are filled, the system compares your CV to the job description. The logic is simpler than most people expect:

# Simplified version of what most matching logic does.
# No intelligence here — just presence, position and frequency.

jd_terms = ["react", "typescript", "accessibility", "design systems"]
cv_text  = extracted_cv.lower()

matched = [term for term in jd_terms if term in cv_text]
score   = len(matched) / len(jd_terms)

print(score)          # 0.5
print(set(jd_terms) - set(matched))   # {'accessibility', 'design systems'}

Two things follow from this.

First: synonyms do not count. If the job description says "design systems" and your CV says "component library", you built the same thing and score zero on that term. The system is not reading for meaning.

Second: placement matters. A skill mentioned once in a list at the bottom carries less weight than the same skill inside a recent role, where it sits next to a company and a date.

So the fix is not to invent skills. The fix is to use the employer's vocabulary for work you have genuinely done, and to move it somewhere visible.

Stage 3: Filtering — a human still decides

This is where the myths come from. You may have read that a large percentage of CVs are "rejected by robots". I have never found a source for those numbers that holds up, so I do not quote them.

What is true is more boring. The recruiter opens a ranked list. They look at the top of it. Being on page four is not a rejection, it is an absence.

Staying visible means three things:

Be parseable, so your fields are filled and searchable.
Be relevant, so you rank against this specific job.
Be readable, because a human opens the file straight after.

Optimising for the machine at the cost of the human is a trap. Keyword-stuffed white text still fails when someone actually reads it.

How we built CVSet around these three stages

I am the founder and product designer of CVSet. The product exists because of one rule we refused to break: same facts, better visibility. The AI never invents a skill, a job, or a number. It reorganises and highlights what is already in your CV.

Here is how the flow maps onto what an ATS does.

1. Analyse — score the CV before anything is changed

You upload a CV and get a score across nine dimensions, including ATS Keywords, Formatting, Readability and Metrics & Impact.

The same CV is also viewed through four perspectives: Hiring Manager, Recruiter, Human Eye and Algorithm. The Algorithm view is the parsing story above. The Human Eye view is the recruiter who opens the file afterwards. A CV can pass one and fail the other, and you need to see both.

Scores are shown with an honest ceiling. If a CV cannot reach 100 for a real reason, we do not pretend it can.

2. Optimise — fix the structural problems

The analysis produces suggestions you resolve one at a time. Formatting suggestions are the ones that protect parsing: single-column flow, contact details in the body, real text instead of images, standard section names.

One decision here took us a long time to get right. Early on, our formatting logic removed photos from CVs automatically, because photos are unusual on UK and US CVs and can confuse a parser. That was wrong. In Germany and several other markets, a photo is a normal expectation.

We had built a silent destructive action, which is the worst kind of bug: nothing errors, the user just loses something.

The fix was to separate two decisions that we had wrongly merged:

Format:  [ UK ▾ ]   → sets layout conventions only
Photo:   ( ) Keep photo   ( ) Remove photo   → you must choose

The format dropdown never touches the photo. The photo decision is explicit and always per CV. Never let an automated fix quietly delete the user's content.

3. Tailor — match one CV to one job description

This is Stage 2 handled properly. You paste a job description and CVSet evaluates the match across five dimensions:

Dimension	Weight
Skills	30%
Keywords	25%
Language	20%
Quality	15%
Prioritisation	10%

The output tells you which required skills you already demonstrate and which are genuinely missing. Matching skills get the employer's wording and move up the page. Missing ones do not get invented. They go to your To-Learn List instead, which is the honest answer to a gap.

You can also skip tailoring entirely and use CVSet as a lightweight application tracker.

4. Application Pack — everything after the CV

Once tailored, you can generate a tailored CV, a cover letter, likely interview questions, first-call prep questions and a follow-up email. It is credit-based, so you only generate what you need.

5. AI Report — patterns across applications

After five finalised tailored applications, CVSet aggregates what it has seen: which skills keep appearing in the jobs you target, where your CV consistently loses points, which roles you match best. Five is a real threshold, not a marketing number. Below that, the pattern is noise.

CVSet runs on a one-time credit purchase with no subscription and no auto-renewal, and data is deleted 30 days after purchase by design.

What I learned building this

Parsing failures look like writing failures. People rewrite their bullet points when the real problem is a table.
Two-column CVs are not banned, they are risky. If you use one, keep the reading order sane and keep contact details in the main flow.
Never guess on the user's behalf. Our photo bug taught us that a helpful automatic action is still destructive if the user did not choose it.
Honesty is a feature. Refusing to invent skills costs you a flashy demo and buys you a product people can actually send to an employer.
The machine and the human need the same document. Anything that helps one at the expense of the other is a bad trade.

Key Takeaways

An ATS parses, ranks and filters. It does not reject you with an opinion.
Parsing is the stage most CVs lose. Empty fields cannot be searched.
Keep contact details in the body, use standard section headings, and avoid tables, text boxes and image-only PDFs.
Keyword matching is literal. Use the employer's wording for work you have really done.
Skills carry more weight inside a recent role than in a list at the bottom.
Being unranked is absence, not rejection. Tailor per job to stay near the top.
Never let a tool add skills you do not have, or remove content you did not agree to lose.

Over to you

What is the strangest parsing failure you have hit? I am collecting real examples, and the sidebar-swallows-the-job-history one still wins in our team.

If this is useful, my next post will go deeper on one thing: why "demonstrated" has to be decided at tailoring time and stored, instead of being guessed again every time the page loads. It sounds like an implementation detail. It changes what the user is allowed to trust.

You can try the scoring at cvset.io.

Stop Rewriting Your CV: Tailor One Base CV for Every Job Application

Mo — Tue, 01 Sep 2026 08:07:18 +0000

I used to keep six versions of my CV in one folder. CV_final.docx, CV_final_v2.docx, CV_final_REAL.docx. Every application meant twenty minutes of copy, paste and guilt — and I still had no idea if the new version was better than the old one. So we built the thing I wanted: one strong base CV, scored honestly, then tailored per job without touching the facts.

TL;DR

Rewriting your CV per job is the wrong loop. Fix the base CV once, then tailor it per job.
Tailoring is reordering, not inventing. Same facts, better visibility.
Score before you edit. You cannot improve what you have not measured.
CVSet does this in three steps: Analyse → Optimise → Tailor.
Everything below also works manually. The tool just removes the boring part.

The problem with "rewrite it for each job"

Most CV advice says the same thing: tailor your CV for every role. True, but useless on its own. It leaves you with two bad options.

Option A — send the same CV everywhere. Fast, but your best experience sits in the wrong order for that specific role.

Option B — rewrite it every time. Slow, and quality drops after application number four. You get tired, you get sloppy, and by Friday you are inventing a "passion for scalable systems" you do not have.

Both options fail for the same reason. They treat the CV as one object, when it is really two layers:

Facts — what you did, where, when, with what result. These never change.
Presentation — order, wording, emphasis, keywords. These should change per job.

Once you separate those layers, the work gets much smaller.

The rule we would not break: same facts, better visibility

Before writing a line of code, we set one hard constraint for CVSet:

The AI never adds a skill, a job, a number or an achievement that is not already in your CV.

No invented Kubernetes. No rounded-up team sizes. No "led" when you contributed.

This sounds limiting. It is actually the whole product. If a tool can invent, you can never trust its output — you have to re-read every line to check it did not lie about you. If it cannot invent, you can trust it and move on.

So tailoring means only four moves:

Reorder — put the relevant experience higher.
Reword — match the language the job description uses.
Resurface — pull a buried bullet point up into view.
Trim — cut what is not relevant to this role.

That is it. Nothing else.

Step 1 — Score the base CV first

Do not tailor a weak CV. You will just produce weak CVs faster.

CVSet scores your base CV across nine dimensions, including Metrics & Impact, Readability, ATS Keywords, Clarity & Brevity and Formatting. Each one is scored from four perspectives: hiring manager, recruiter, human eye, and algorithm.

The scores are not decoration. They tell you where the cheapest wins are. A CV scoring low on Metrics & Impact usually has bullets like this:

❌ Before
- Responsible for improving the checkout flow.

✅ After
- Rebuilt the checkout flow, cutting drop-off from 34% to 21% in one quarter.

Same fact. The number was always true — it was just missing from the page.

Step 2 — Optimise once, not per job

The Optimise step turns the analysis into specific suggestions on specific lines. You resolve them once, on your base CV.

This is the part people skip, and it is the part that pays. Fixing "no quantification in the last three roles" once improves every future application. Fixing it per job means fixing it forty times.

Rule of thumb: if a fix would apply to any employer, it belongs in the base CV. If it only makes sense for one company, it belongs in tailoring.

Step 3 — Tailor against a real job description

Now the per-job work. You pick which base CV to use, and paste the job description.

Two details in that screen took the longest to get right.

Multiple base CVs, not one. People applying across countries need different conventions — a German CV and a UK CV are genuinely different documents. Each one keeps its own score.

"Continue without tailoring". Sometimes you already applied elsewhere and just want to track the application. Forcing tailoring would make the tool annoying, so we made it optional.

Then it runs. Nine steps, one to two minutes.

We show the step count on purpose. A silent spinner for ninety seconds feels broken. A labelled step feels like work happening.

Step 4 — Read the match score honestly

The tailoring result is a weighted score across five dimensions:

match = (skills        × 0.30)
      + (keywords      × 0.25)
      + (language      × 0.20)
      + (quality       × 0.15)
      + (prioritisation× 0.10)

Skills carries the most weight because it is the least fixable by rewording. If the role needs three years of Kubernetes and you have none, no amount of clever phrasing will close that gap — and the tool should say so, not hide it.

That 51 is the screenshot I nearly did not use. It would have been easy to show a 94.

But a tool that always says you are great is a tool that tells you nothing. 51 / NEEDS WORK is the honest, useful answer — this CV is not ready for this role yet, and here is what is missing. A gap you can see is a gap you can close, either by editing or by applying elsewhere.

Key Takeaways

Split your CV into facts (fixed) and presentation (per job). Only the second layer should change.
Fix the base CV once. Base-CV improvements compound across every application.
Tailoring = reorder, reword, resurface, trim. Never invent.
Match the employer's vocabulary, not your preferred synonym.
A low score you can act on beats a high score that flatters you.
Keep separate base CVs per region if you apply internationally.

Your turn

What is your current process — one master CV, or a folder full of _final_v3 files? And if you tailor manually, what is the one step you refuse to skip? I am curious whether the 10-keyword rule matches what other people do.

Next post, I want to go deeper into the scoring side: why we cap some dimensions below 100, and why an honest ceiling is more useful than a perfect score.

You can try the flow at cvset.io.

Beyond Localhost: Implementing Production-Grade Entra ID Auth in .NET Aspire

Mo — Sun, 10 May 2026 17:03:44 +0000

We’ve all been there. You spend two days wiring up authentication for a distributed project. It works perfectly on your machine with a mock provider or a local database, but the moment you try to integrate a real enterprise identity provider like Microsoft Entra ID, the wheels come off. Redirect URIs don't match, audience validation fails, and your local environment feels nothing like the production environment you're supposed to be targeting.

When I started building out my latest CleanArchitecture template, I wanted to solve this once and for all. I wanted an architecture where switching between an open-source provider like Keycloak and an enterprise-grade one like Entra ID was a matter of a single configuration switch, not a week of refactoring.

In this guide, I’m going to walk you through how to implement a production-ready Entra ID authentication flow within a .NET Aspire project. We’re going to look at the architectural "why," the specific Entra portal configuration, and the plumbing required to keep your local development environment sane.

The Identity Architecture: The "Three-Registration" Strategy

One of the most common mistakes I see in senior-level designs is trying to use a single Entra App Registration for every component in a distributed system. While it's easier to set up, it’s a security and maintenance nightmare.

In a true Clean Architecture approach, we separate concerns. In this project, I’ve structured the identity flow around three distinct registrations:

The API (The Resource Server): This is the gatekeeper. It doesn't handle "logins" or UI. Its sole job is to receive a Bearer token, validate the signature against Microsoft’s keys, and check if the aud (audience) and scp (scopes) claims allow the requested action.
The React App (The Public Client): This is the Next.js frontend using NextAuth.js. It performs the "heavy lifting" of the OIDC (OpenID Connect) flow. It interacts with the user, handles the redirect back from Microsoft, and securely stores the tokens.
The Scalar UI (The Developer Client): Because we use Scalar for API documentation and testing, it needs its own identity. This allows developers to authenticate directly against the API without needing the React frontend running, which is a massive productivity boost.

Step 1: Entra Portal Configuration

To follow along with the CleanArchitecture repo, you’ll need to create three registrations in the Entra portal.

1. The API Registration

Name: CleanArch-API
Supported account types: Single Tenant Only
Expose an API: Define a new scope called access_as_user.
Application ID URI: Set this to something unique (e.g., api://your-app-id).

2. The React App Registration

Name: CleanArch-Web
Supported account types: Single Tenant Only
Authentication: Add a "Web" platform.
Redirect URI: http://localhost:65499/api/auth/callback/azure-ad
Secret: Generate a Client Secret (store this safely).
API Permissions: Select "Your APIs" and check the access_as_user permission from the API registration.

3. The Scalar Registration

Name: CleanArch-Scalar
Supported account types: Single Tenant Only
Authentication: Add a "Single-page application" (SPA) platform.
Settings: Access tokens (used for implicit flows)
Redirect URI: http://localhost:5049/scalar/

Step 2: Configuring the Frontend (Next.js & NextAuth)

In a .NET Aspire project, the frontend often runs as a Node.js resource. In my project, I use Next.js. The key here is the .env.local file. I've designed this to be "provider agnostic"—you can toggle between Keycloak and Entra ID.

For Entra ID, your config should look like this:

# .env.local
API_BASE_URL=http://localhost:5049/
NEXTAUTH_URL=http://localhost:65499

# Generate this using: node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"
NEXTAUTH_SECRET=YourSuperSecretRandomString 

# The Toggle
AUTH_PROVIDER=Entra 

# Entra ID Details
ENTRA_CLIENT_ID=<React-App-Client-ID>
ENTRA_CLIENT_SECRET=<React-App-Client-Secret>
ENTRA_TENANT_ID=<Your-Tenant-ID>
ENTRA_SCOPES=openid profile email api://<API-Client-ID>/access_as_user
ENTRA_OPENID_CONNECT=https://login.microsoftonline.com/<Tenant-ID>/v2.0/.well-known/openid-configuration

Senior Insight: Note the ENTRA_SCOPES. We aren't just asking for openid. We are explicitly requesting the scope defined in our API registration. Without this, Entra will return an ID Token but a generic Access Token that your API will reject with a 401.

Step 3: Wiring Up the .NET API

The API sits within the CleanArchitecture.Presentation/API project. Since we are using .NET Aspire, we want our configuration to be clean and easily overridden by the AppHost.

Inside appsettings.Development.json, we configure the AzureAd section and the ScalarApi section:

{
  "Authentication": {
        "Provider": "Entra"
    },
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "your-org.onmicrosoft.com",
    "TenantId": "...",
    "ClientId": "<API-Client-ID>",
    "Audience": "<Audience-ID>",
  },
  "ScalarApi": {    
    "ClientId": "<Scalar-Client-ID>",
    "Scopes": "openid profile email api://<Your-API-Client-ID>/access_as_user",
    "AuthorizationUrl": "<Authorisation-URL>",
  }
}

Why Scalar?

Most .NET devs are used to Swagger. However, Scalar provides a much more robust "Try It Out" experience, especially for OAuth2/OIDC. By providing the ScalarApi config here, the Scalar UI will automatically show an "Authorize" button that initiates the Entra login flow using the Scalar App Registration.

Step 4: The .NET Aspire Orchestration

This is where the magic happens. In the AppHost project, we coordinate these services. The beauty of Aspire is that it handles the environment variable injection for us.

When you run the AppHost, it reads these settings and ensures that the API and the Web frontend are aware of each other. If you change a port in Aspire, you only have to update your Entra Redirect URIs once, rather than hunting through multiple launchSettings.json files.

Hard-Learned Lessons & Trade-offs

1. The Managed Identity Pivot

In local development, we use Client Secrets because they are easy. However, the moment this code moves to Azure via azd up, you should pivot to Managed Identity. .NET Aspire’s Azure components make this easy, but you must ensure your code uses DefaultAzureCredential and avoid keeping secrets in your configuration files.

2. No CORS Nightmare (Thanks to the BFF Pattern)

In a traditional SPA → API setup, the browser calls the API directly, which immediately triggers the usual CORS chaos — mismatched origins, blocked Authorization headers, and endless tweaking of Program.cs.

But in this project, the BFF (Backend‑for‑Frontend) pattern eliminates that entire class of problems.

Your React/Next.js app never calls the API from the browser.

Instead, all API traffic flows like this:

Browser → Next.js Server (BFF) → .NET API

Because the browser only communicates with the same origin (your Next.js server), there is no cross‑origin request, and therefore no CORS configuration is required in your .NET API.

The BFF handles:

Attaching the user’s access token securely on the server
Forwarding requests to the API
Keeping tokens out of the browser entirely
Ensuring the API only ever receives server‑to‑server calls

This results in a dramatically simpler and more secure setup.

Local development becomes frictionless, and production behaves exactly the same, no special CORS rules, no exposed tokens, no surprises.

3. Keycloak as a Fallback

Why did I keep Keycloak in the project? Because Entra ID requires an internet connection and an active Azure subscription. For "offline" development or lightning-fast integration tests, spinning up a Keycloak container via Aspire is a godsend. It ensures that the team can keep working even if Azure is having a bad day.

Path to Production: `azd up`

One of the primary reasons to use this specific project structure is the deployment story. Because this is a .NET Aspire project, you can run:

azd up

The Azure Developer CLI will look at your AppHost, generate the necessary Bicep files, and provision your Azure Container Apps, Key Vault, and Log Analytics. Because we've separated our App Registrations, we can easily map them to environment variables in the Azure production environment, ensuring a seamless transition from "it works on my machine" to "it works in the cloud."

Conclusion

Identity is often the "final boss" of software architecture. By using .NET Aspire and following the Clean Architecture patterns laid out in this repository, you turn a complex, error-prone manual process into a repeatable, configuration-driven workflow.

**Have you made the jump to .NET Aspire yet?
What’s been your biggest challenge with Entra ID integration?

Let’s discuss in the comments.**

Claude Opus 4.6 vs. GPT 5.4

Mo — Sun, 29 Mar 2026 17:10:27 +0000

Claude Opus 4.6 vs. GPT 5.4: My Take as a C#/.NET Dev on AI Coding Companions

Alright team, let's talk AI. As a senior engineer who's spent more years than I care to admit wrangling C# and .NET, I've seen my fair share of "game-changing" tech. Most of it is just hype. But these new-gen LLMs? They're different. We're talking about legitimate productivity boosters, especially when you're staring down a tricky bug or architecting a new microservice.

Lately, I've been putting the big two — Claude Opus 4.6 and GPT 5.4 — through their paces specifically for coding tasks. The question isn't if they're useful, but which one to bring to the fight, or if we should be thinking "both." Let's dive into my real-world experiences.

The Setup: My C#/.NET AI Playground

Before we get into the nitty-gritty, a quick word on my testing environment. I wasn't just asking them to write "Hello World." I was throwing real-world problems at them: building complex LINQ queries, designing a robust API controller, refactoring legacy code, even trying to get them to write xUnit tests for some tricky asynchronous logic.

I wanted to see how they handled:

Context: Can they keep track of a larger codebase or conversation?
Precision: Do they generate code that actually compiles and runs correctly the first time?
Nuance: Can they understand why I'm asking for something, not just what?
Debugging: How good are they at finding issues in their own code or mine?

GPT 5.4: The Speedy Generalist with a Few Surprises

GPT 5.4 feels like that incredibly bright junior developer who's read every programming book but sometimes misses the specific context of our project. It's fast, incredibly broad in its knowledge, and often provides surprisingly elegant solutions right out of the gate.

When I needed boilerplate code for a new DbContext or a standard ASP.NET Core controller, GPT 5.4 was lightning-fast and usually spot-on. It's fantastic for generating common design patterns or even suggesting different approaches to a problem.

Where it Shines:

Broad Knowledge Base: If it's a common C# pattern, a widely used .NET library, or a general algorithm, GPT 5.4 knows it.
Code Generation Speed: It often generates long code blocks quickly, perfect for getting a first draft down.
Exploration: Great for brainstorming different ways to solve a problem or exploring new libraries.

Where I Pump the Brakes:
Sometimes, GPT 5.4 can be a bit too confident. It occasionally generates plausible-looking code that has subtle bugs, or it might make assumptions about my project that aren't true. I've also found it can "forget" earlier parts of our conversation if the thread gets too long. It's like it gets distracted by the next shiny coding problem.

Claude Opus 4.6: The Meticulous Architect, Slow and Steady

Claude Opus 4.6, on the other hand, feels more like a seasoned architect. It's often slower to respond, but its answers tend to be incredibly thoughtful, detailed, and deeply contextual. It seems to "think" more before responding, often asking clarifying questions or laying out its reasoning step-by-step.

For complex refactoring tasks, or when I was trying to optimize a specific piece of asynchronous code for performance, Claude truly stood out. It provided not just the code, but the rationale behind the choices, often citing best practices or potential pitfalls. It felt like pair programming with someone who meticulously considers every angle.

Where it Shines:

Contextual Understanding: It maintains context over very long conversations, making it excellent for multi-step tasks or complex debugging.
Deep Reasoning: Its explanations are often superb, breaking down complex problems and justifying its code choices.
Fewer Hallucinations: I've found it to be more reliable in generating correct, runnable code without subtle errors. It double-checks its work, which is invaluable.
Refactoring & Debugging: Excellent at identifying issues in existing code and suggesting robust improvements.

Where I Feel the Pinch:
The speed. Sometimes, when you just need a quick IEnumerable extension method or a simple DI setup, waiting for Claude's detailed explanation can feel a bit overkill. It's not a rapid-fire code generator in the same way GPT 5.4 can be.

The Verdict: Don't Choose, Combine!

After weeks of real-world use, my conclusion is clear: you don't have to pick just one. These aren't competitors; they're complementary tools in a modern software engineer's arsenal.

Think of it this way:

Reach for GPT 5.4 when:
- You need rapid prototyping or boilerplate generation.
- You're exploring new libraries or frameworks and need quick examples.
- You're stuck on a common problem and need a few different potential solutions fast.
- You need simple, isolated code snippets.
Reach for Claude Opus 4.6 when:
- You're working on complex architectural decisions or refactoring significant parts of your codebase.
- You need detailed explanations, best practices, and a deeper understanding of why certain code is structured a certain way.
- You're debugging persistent, tricky issues and need a methodical, logical approach.
- You have a long, ongoing conversation about a specific problem and need the AI to maintain deep context.

I often start with GPT 5.4 for initial drafts or quick ideas. Then, if I hit a wall, or if the problem requires more nuanced reasoning, I'll port the conversation (or at least the core problem) over to Claude Opus 4.6 for a more in-depth architectural review or a meticulous debugging session. It’s like having a brilliant junior dev for the grunt work and an experienced architect for the heavy lifting.

Your AI Pair Programming Partner(s)

Adopting these tools isn't about replacing engineers; it's about augmenting our capabilities. It's like having a super-powered pair programmer who never gets tired and has read the internet. For us C# and .NET folks, understanding the strengths of both Claude Opus 4.6 and GPT 5.4 means we can write better code, faster, and with fewer headaches.

What are your experiences? Have you found one to be clearly superior for your specific tech stack, or are you also seeing the value in a multi-model approach? Let me know in the comments!

C# Keeps Getting Better: My Favourite Modern Language Features

Mo — Sat, 28 Mar 2026 11:48:16 +0000

If you've been coding in C# for a while, you know it's a language that refuses to sit still. Every new version brings a fresh set of tools, and honestly, as someone who's been wrangling .NET for years, it's pretty exciting to see how much more expressive, concise, and just plain fun C# has become. Gone are the days of endless boilerplate for simple tasks!

Let's dive into some of the features that have genuinely changed how I approach C# development.

Streamlining Your Code: Less Ceremony, More Action!

One of the biggest shifts in recent C# versions has been a strong push towards reducing boilerplate. We're all busy, right? Why type more when you can say the same thing with less?

Top-Level Statements: Kickstarting Your Apps

Remember when even a simple "Hello World" console app needed a namespace, a class, and a static void Main(string[] args)? It felt a bit heavy for quick scripts or learning examples. Well, say hello to top-level statements!

Now, your entire program can look like this:

// Program.cs
Console.WriteLine("Hello, modern C#!");

// You can even use async/await directly
await Task.Delay(100);
Console.WriteLine("Waiting is over!");

This is fantastic for small utilities, Azure Functions, or just getting an idea off the ground without the cognitive load of a full class structure. It makes C# feel much more scripting-friendly.

Global Using Directives: De-cluttering Your Files

How many times have you scrolled past a dozen using statements at the top of every file? System, System.Collections.Generic, System.Linq, Microsoft.EntityFrameworkCore... the list goes on.

global using directives let you declare these common using statements once for your entire project. Just drop them into a file (often GlobalUsings.cs or Usings.cs), and they're available everywhere.

// GlobalUsings.cs
global using System;
global using System.Collections.Generic;
global using System.Linq;
global using Microsoft.EntityFrameworkCore;
// ...and so on

The difference this makes in larger projects is immense. Your individual files become cleaner, focusing purely on the code within. No more endless scrolling past using blocks!

Embracing Immutability: Records & `init` Setters

Immutability is a huge win for robust, predictable software. When an object's state can't change after it's created, you eliminate entire classes of bugs related to unexpected side effects. C# has made it a first-class citizen with records and init setters.

Record Types: The Data-First Class

Records are essentially classes (or structs) designed for immutable data models. They come with a ton of goodies out of the box, like value-based equality, concise syntax, and non-destructive mutation (with expressions).

Imagine you're defining a Data Transfer Object (DTO) or an entity:

// Old way (class) - lots of boilerplate for immutability, equality, and ToString
public class Product
{
    public int Id { get; }
    public string Name { get; }
    public decimal Price { get; }

    public Product(int id, string name, decimal price)
    {
        Id = id;
        Name = name;
        Price = price;
    }
    // Need to override Equals, GetHashCode, ToString manually...
}

// New way (record) - concise, immutable by default, value equality
public record Product(int Id, string Name, decimal Price);

That's right, a single line! Records are perfect for scenarios where you just need to represent data. They save you from writing mountains of boilerplate for Equals, GetHashCode, and ToString, and they promote a functional style of programming.

`init` Setters: Immutable Properties, Flexible Creation

Even with regular classes, init setters provide a powerful way to ensure properties can only be set during object initialisation, enforcing immutability after creation.

public class UserProfile
{
    public int Id { get; init; } // Can only be set during object creation
    public string Username { get; init; }
    public DateTime RegisteredDate { get; init; } = DateTime.UtcNow; // Default value also works

    // Usage
    var user = new UserProfile { Id = 1, Username = "devfriend" };
    // user.Id = 2; // Error: Init-only setter cannot be used here
}

This gives you the best of both worlds: object initialiser syntax for easy construction, and immutability once the object is fully formed. Super handy for configuration objects or read-only view models.

Smarter Decisions: Enhanced Pattern Matching

Pattern matching isn't new, but it's been steadily enhanced, making complex conditional logic incredibly readable and concise. It allows you to test an expression against various "patterns" and execute code based on a match.

`switch` Expressions and Property Patterns

Gone are the days of clunky switch statements with case and break. switch expressions are, well, expressions – they return a value, making them perfect for transformations. Combine that with property patterns, and you have some serious power.

// Imagine a DTO or some input object
public record OrderItem(string ItemType, int Quantity, decimal UnitPrice);

public decimal CalculateDiscount(OrderItem item) => item switch
{
    // If ItemType is "Book" AND Quantity > 5, apply 10% discount
    { ItemType: "Book", Quantity: > 5 } => item.Quantity * item.UnitPrice * 0.10M,
    // If ItemType is "Software" AND UnitPrice > 100, apply 5% discount
    { ItemType: "Software", UnitPrice: > 100 } => item.Quantity * item.UnitPrice * 0.05M,
    // Any other case
    _ => 0M
};

// Even simpler: type patterns
public string GetShapeInfo(object shape) => shape switch
{
    Circle c when c.Radius > 10 => $"Large Circle with radius {c.Radius}",
    Circle c => $"Small Circle with radius {c.Radius}",
    Rectangle r => $"Rectangle {r.Width}x{r.Height}",
    _ => "Unknown shape"
};

This syntax is incredibly powerful for expressing intent clearly. Instead of nested if/else if statements, you get a clean, declarative structure that's easy to read and maintain.

Wrapping Up

These are just a few of my personal highlights from the recent evolutions of C#. From making quick scripts easier with top-level statements to building robust, immutable data models with records, and writing more expressive conditional logic with pattern matching, C# continues to empower developers to write cleaner, more maintainable code.

It's a fantastic time to be a C# developer, and I'm always excited to see what's next!

What new C# feature has made the biggest difference in your daily coding life? Let me know in the comments!

Migration from .NET 4.7 to .NET 10

Mo — Sun, 07 Dec 2025 14:32:14 +0000

Travels in Time:

The Great Migration from .NET Framework 4.7 to .NET 10 🚀

All of us have encountered this situation: inheriting a project that has remained untouched for years, only to discover it is now outdated. Recently, I was assigned to such a project with a clear directive to modernise a legacy application built on .NET Framework 4.7 and successfully migrate it to the latest LTS release, .NET 10.

It was a journey filled with architectural archaeology, AI tooling, and some tough decisions. Here is the story of how we managed the upgrade of this legacy application using Visual Studio 2026, and what we learned along the way.

🧐 Phase 1: The Archaeology

My journey began with a classic induction meeting with my Line Manager and Product Owner. Once the pleasantries were done, I popped the hood to see how the project was structured.

As expected with legacy code, there wasn't much of a "structure" to speak of. It was a flat architecture where almost all business logic lived directly inside the Controllers. Even worse, database contexts were being instantiated right there in the controller methods, something like this:

public class LegacyController: Controller {
    public ActionResult Index() {
        // Direct instantiation inside the controller? Check.
        using (var db = new MyDbContext()) { ... }
    }
}

I knew that if I started refactoring immediately, I would generate a massive amount of changes that would be impossible to review properly, increasing the risk of failure.

The Initial Health Check

I decided to run the application to understand the flow without getting bogged down in the nitty-gritty of every single class. I also ran the existing unit tests. Unsurprisingly, red lights flashed everywhere.

The project lacked a proper CI/CD pipeline, so over time, business logic had drifted, while the tests had been forgotten.

📋 Phase 2: The Battle Plan

I went back to the Azure Board and tagged my Line Manager and PO with a plan. I proposed a strict order of operations to mitigate risk:

Stabilize: Pass all current unit tests to ensure the application works before we touch the framework.
Upgrade: Move the project directly from .NET Framework 4.7 to .NET 10.
Modernise: Once stable on .NET 10, implement a proper CI/CD pipeline in Azure DevOps.

I spent a few days fixing bugs in the test suite until everything was green. Only then was I ready for the big lift.

🛠 Phase 3: The Upgrade (Dependencies & AI Tools)

Using the newly released Visual Studio 2026, I started by auditing our NuGet packages and third-party references.

The Third-Party Challenge

One significant hurdle was a reference to Excel-DNA. When upgrading, checking vendor compatibility is non-negotiable. I had to comb through their documentation to find their specific upgrade process for .NET 10 compatibility.

The Entity Framework Dilemma

We were also using Entity Framework 6 (EF6). While EF6 is technically compatible with .NET 10, the long-term goal is obviously Entity Framework Core. However, trying to do that migration simultaneously would have blown up the scope. My manager and I agreed: get to .NET 10 first, upgrade to EF Core later.

AI vs. Legacy Tools

Visual Studio 2026 offers a tool called Modernizer, which leverages AI (ChatGPT, Gemini, Claude) to handle upgrades.

Tool	Verdict
Modernizer (AI)	Fantastic for simple class libraries. It proposed excellent upgrade plans and did the heavy lifting.
Legacy Upgrade Assistant	Necessary for the complex UI projects. The AI struggled with our old AngularJS/MVC mix, so I had to enable this legacy tool via `Tools > Options`.

🏗 Phase 4: Execution

Step 1: Low-Hanging Fruit

I started with the solution's four projects. Three were simple class libraries, so I used the Modernizer AI tool to upgrade them to .NET 10 first.

Pro Tip: When upgrading, resist the urge to use new features immediately. .NET 10 has cool toys like file-scoped namespaces, but mixing feature changes with framework upgrades creates noisy Pull Requests (PRs). I kept the code changes minimal so my team could actually review the PR.

Step 2: The Web Project (The Beast)

The main website was an ASP.NET MVC application with AngularJS. The Legacy Upgrade Assistant handled the C# conversion well, but it had no idea what to do with the UI.

The Bundling Problem:
Old ASP.NET had built-in bundling for CSS and JS. .NET 10 doesn't work that way. I had to:

Find npm equivalents for our NuGet client-side packages.
Implement a new build process.

I decided to use Gulp to compile our TypeScript and LESS files and bundle them. I utilised AI heavily to generate the Gulp tasks (which worked perfectly), creating a single output file referenced in our index.html.

Step 3: The Inevitable Refactor

Here is where I had to break my own rule about "minimal changes." The old code was so non-SOLID that I literally couldn't inject the services I needed into the controllers.

I had to refactor the presentation layer, introducing the Unit of Work pattern and cleaning up the dependency injection. It made the PR larger, but it was unavoidable to get the application running.

✅ Phase 5: Crossing the Finish Line

With the refactoring done, I ran the project. Miraculously (or perhaps due to the preparation), it worked.

I performed end-to-end testing, deployed to the test environment, and handed it over to QA. Everything looked green. I opened the PR, which was only "50% of the job" considering the future work needed, but the platform was now on .NET 10.

🔮 What's Next?

We successfully reached .NET 10, but the journey isn't over. We still need to upgrade to EF Core and add observability.

However, the business has shifted priorities. The old AngularJS frontend is now a security vulnerability. We aren't just upgrading to modern Angular; my manager wants a complete rewrite of the presentation layer using React.

There’s just one catch: I don't know React very well yet.

It’s going to be a challenging task, but I plan to tackle it head-on. Stay tuned, I’ll be sharing how I manage that learning curve in my next post.

Happy coding!

🚀 Event-Driven Architecture (EDA): The Power of Reacting to Events

Mo — Mon, 03 Nov 2025 07:48:16 +0000

Hey everyone 👋

Today, we’re diving into one of my favourite software architecture topics, Event-Driven Architecture (EDA). It’s one of those patterns that sounds a bit fancy at first, but once you understand it, you start seeing it everywhere: in cloud applications, microservices, and even your daily notifications!

Let’s break it down step by step. ☕

🧩 What Is Event-Driven Architecture?

At its core, Event-Driven Architecture is all about reacting to events.

An event is simply something that happened, for example:

An order was placed 🛒
A payment was completed 💳
A user logged in 👤

Instead of having tightly coupled services that directly call each other (as in layered or traditional microservice architectures), EDA uses events as the main form of communication.

Here’s where the magic happens ✨:
In EDA, each service acts independently. When something happens, a service simply publishes an event, it’s like saying:

“Hey, an order was placed!”

But here’s the cool bit: the service that emits the event doesn’t know (or care) who is listening, when they’ll react, or how they’ll process it.

That’s a big contrast to traditional architectures, where services often directly call one another through APIs.

EDA, on the other hand, is asynchronous and decoupled. Services communicate via an event broker (or message queue), meaning they’re completely independent; they just publish events into a queue without caring who processes them later.

💡 Why EDA Matters

This independence makes EDA:
✅ Highly scalable
✅ Fault-tolerant
✅ Easier to evolve over time

But it’s not always simple. While EDA offers powerful flexibility, it also introduces complexity. So before jumping in, we need to answer a few important questions 👇

🧠 Key Questions to Understand EDA

What’s the difference between an event and a message?
How do we ensure no data loss?
How many brokers or queues do we need?
How do we track state across multiple services?

Let’s explore each one.

🔁 Events vs. Messages

In EDA, the main concept is an event.

When an event is raised, we don’t care who processes it or when. The system just publishes the event, fire and forget. 🔥

Events: Fire and forget. The publisher emits and moves on.
Messages: Commands or queries, requests that expect a result.

So, in message-driven architecture, a message waits for a response, while in event-driven architecture, we publish and continue working asynchronously.

Most EDA systems use a Pub/Sub pattern, one service publishes events and others subscribe to them.
In contrast, message-driven systems usually use point-to-point communication since the sender knows exactly which service should handle the message.

🧱 Ensuring No Data Loss

One of the biggest challenges in EDA is data integrity.

Imagine this:

A service publishes an event to a queue, but right after that, the queue crashes, and the event is gone! 😱
Or maybe the consumer reads the event but fails before saving it to the database, and the data is lost again!

To prevent this, we can use the Event Forwarding Pattern 🛡️

Here’s how it helps:

Persist Events, Before a service sends an event to the queue, it first persists it in durable storage.
Recover Gracefully, If a service crashes after reading an event, it can re-fetch it later because the queue retained a persisted copy.
Track Consumers, Store client IDs so each service knows which messages it has processed.
Confirm Completion, After saving to the database, the service confirms success so the event can safely be removed from the queue.

This ensures strong data integrity ✅, but it comes with trade-offs:

Lower performance (because of synchronous writes)
Possible duplicate data

So, use this approach when data reliability is more important than throughput.

🏗️ How Many Brokers Do We Need?

Good question! Should each microservice have its own broker, or should they all share one?

Let’s look at the concept of Architectural Quantum, introduced in Building Evolutionary Architectures 🧠

An Architectural Quantum is an independently deployable component with high functional cohesion that includes everything needed for the system to work properly.

If all services depend on a single broker, then if that broker goes down, everything goes down.
This means the entire system is one single architectural quantum.

But if each service has its own broker, then you have multiple independent systems, more resilient, but also more expensive 💸.

A balanced approach is the Domain Broker Pattern:

Each domain gets one broker.
Services within a domain share the same broker.
Domains remain independent of one another.

This gives you a nice balance between cost and independence.

🔍 Managing State in EDA

Tracking the state of an entity (like an order) across distributed services can be tricky. Let’s say you have:

An Order Service 🛒
An Inventory Service 📦
A Delivery Service 🚚

When a user asks, “What’s the status of my order?”, where should we look?

There are two main patterns for managing state:

1️⃣ Push-Based Pattern

Each service writes status updates to a shared queue.
The Order Service listens to this queue and keeps the latest status in its database.

✅ Pros:

Centralized status tracking
Easy to query

⚠️ Cons:

All services depend on one queue → Architectural quantum = 1
A single failure can bring down the whole system

2️⃣ Pull-Based Pattern

In this model, a separate Status Service listens to events from all brokers.
It collects and stores the latest status for each order.

✅ Pros:

No shared dependency, more resilient
Central point for querying order status

⚠️ Cons:

Requires building and maintaining an extra service

🏁 Final Thoughts

Event-Driven Architecture is incredibly powerful; it enables scalable, resilient, and decoupled systems. But like any architecture, it’s not a one-size-fits-all solution.

EDA shines when:

You have many independent services that react to real-time changes
You need asynchronous communication
You care more about flexibility and responsiveness than strict performance

However, it adds complexity in state management, data integrity, and broker design, so plan carefully before adopting it.

Thanks for reading! 🙌
If you found this useful, don’t forget to share it with your fellow developers and let’s keep learning together 💬

Proper Logging in ASP.NET Core

Mo — Wed, 19 Mar 2025 06:49:53 +0000

Hey there, fellow code warriors! 👋 Today, we're diving deep into proper logging in ASP.NET Core. If you've ever found yourself lost in a sea of mysterious bugs or scratching your head over your application's behaviour, this guide is your lighthouse! 🏝️

Why Logging Matters 🤔

Before we jump into the code, let's talk about why logging is the unsung hero of software development. Proper logging is like giving your future self (and your team) a roadmap to understand what's happening in your application. It's not just about catching errors; it's about gaining insights, improving performance, and making your development life easier.

Here's why logging is crucial for your projects:

Application Behavior Monitoring: It's like having a 24/7 surveillance camera on your code.
Event Capturing: Every important moment in your app's life, documented.
Performance Insights: Because sometimes, your app needs a health check.

But logging isn't just about writing stuff down. It's part of a trio of concepts that make your applications robust, maintainable, and scalable:

The Holy Trinity of Application Observability 🛠️

Logging: Your app's diary 📔
- Records events, errors, and important information
- Helps debug issues quickly
- Provides insights into application behaviour
Traceability: Following the breadcrumbs of your code 🍞
- Tracks the flow of application processes
- Follows the lifecycle of requests or commands
- Especially helpful for distributed systems or microservices
- Facilitates debugging and enhances reliability
Metrics: Measuring what matters 📊
- Provides measurable data about application performance
- Helps make data-driven decisions
- Enhances user experiences through targeted optimizations

Implementing Logging with Serilog in ASP.NET Core 🛠️

Let's roll up our sleeves and get our hands dirty with some code! We'll be using Serilog, a powerful logging library for .NET.

Setting Up Serilog

First, add the Serilog.AspNetCore NuGet package to your project. If you're planning to use Azure Application Insights, grab Serilog.Sinks.AzureApp too.

In your Program.cs, set up Serilog like this:

builder.Logging.ClearProviders();
builder.Host.UseSerilog(((context, configuration) => 
    configuration.ReadFrom.Configuration(context.Configuration)));

This code clears any existing logging providers and tells Serilog to read its configuration from the appsettings.json file.

Configuring Serilog

In your appsettings.json, you can configure Serilog like a boss:

{
    "Serilog": {
    "Using": [
      "Serilog.Sinks.Console",
      "Serilog.Sinks.File"
    ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "Console",
        "Args": {
          "theme": "Serilog.Sinks.SystemConsole.Themes.AnsiConsoleTheme::Code, Serilog.Sinks.Console",
          "outputTemplate": "[{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}"
        }
      },
      {
        "Name": "File",
        "Args": {
          "path": "Logs/log-.txt",
          "rollingInterval": "Day",
          "rollOnFileSizeLimit": true,
          "outputTemplate": "[{Timestamp:yyyy-MM-dd HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}",
          "fileSizeLimitBytes": 1073741824
        }
      },
      {
        "Name": "AzureApp",
        "Args": {
          "instrumentationKey": "your_instrumentation_key"
        }
      }
    ],
    "Enrich": [
      "FromLogContext",
      "WithMachineName",
      "WithThreadId"
    ]
  }
}

This configuration sets up Serilog to:

Use both console and file sinks
Set default log levels (Information for production, Debug for development)
Write logs to the console and a file
Send logs to Azure Application Insights

Logging in Action: GlobalExceptionHandler 🎭

Our GlobalExceptionHandler class is like a superhero for exceptions. It catches them, logs them, and sends back a nicely formatted response to the user.

public async ValueTask TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
{
    // ... (exception handling logic)

    _logger.LogError(exception, "An error occurred while processing the request {DateTime} {Path}", 
        DateTime.UtcNow, httpContext.Request.Path);

    // ... (return problem details)
}

This class inherits from IExceptionHandler and is registered in our dependency injection setup. It formats errors based on their type and logs them in a structured way before returning a user-friendly response.

Request Logging with LoggingBehaviour 🕵️

The LoggingBehaviour class is our secret agent, tracking every request that passes through our application.

public async Task Handle(TRequest request, RequestHandlerDelegate next, CancellationToken cancellationToken)
{
    Stopwatch stopWatch = Stopwatch.StartNew();
    logger.LogInformation("Handling request {Name}, {DateTime} ", request.GetType().Name, DateTime.UtcNow);

    // ... (request handling)

    if (stopWatch.ElapsedMilliseconds > SlowRequestThresholdMilliseconds)
    {
        logger.LogWarning("Request took too long to handle {Name}, {DateTime}, {ElapsedMilliseconds}ms", 
            request.GetType().Name, DateTime.UtcNow, stopWatch.ElapsedMilliseconds);
    }

    if (result.IsSuccess)
    {
        logger.LogInformation("Request handled successfully {Name}, {DateTime}", request.GetType().Name, DateTime.UtcNow);
    }
    else
    {
        logger.LogError("Request failed to handle {Name}, {DateTime}, {@Error}", request.GetType().Name, DateTime.UtcNow, result.Errors);
    }

    // ... (log success or failure)
}

This class implements IPipelineBehavior from the MediatR library, acting as a pipeline for each request. It measures request duration, logs warnings for slow requests, and records the outcome of each request.

Pro Tips for Logging Like a Boss 😎

Use Structured Logging: Always include relevant context in your logs. Serilog makes this easy with templates.
Log Levels Matter: Use the right log level for the right situation. Not everything is an error!
Performance Matters: Logging can impact performance, so use it wisely.
Sensitive Data Alert: Be careful not to log sensitive information. Your logs shouldn't be a security risk!
Use the "@" Symbol: When logging objects with Serilog, use the "@" symbol (e.g., {@Error}) to serialize the entire object. This makes querying logs easier, especially with tools like Seq.

Wrapping Up 🎁

Proper logging is an essential skill for any developer working with ASP.NET Core. It's not just about catching errors; it's about gaining insights, improving performance, and making your development life easier.

Remember, your logs are your best friend when things go wrong (and even when they don't). They're your application's black box, recording every important event and helping you understand what's happening under the hood.

So, the next time you're debugging a tricky issue or trying to understand why your app is behaving weirdly, remember: that your logs are there to help. Happy logging, developers! 🚀

The source code is available in my Github repo.

JWT Authentication & Authorization in ASP.NET

Mo — Tue, 04 Mar 2025 18:06:31 +0000

Hey everyone, welcome to our deep dive into JWTs in ASP.NET Core! Whether you’re a beginner or a seasoned developer, this article will guide you through the ins and outs of implementing secure authentication and authorization using JSON Web Tokens (JWT). Grab your favourite beverage, sit back, and let’s get started! 😊

What is JWT? 🔍

JWT stands for JSON Web Token. Think of it as a digital passport that securely transmits information between parties. It’s compact, URL-safe, and self-contained, meaning all the necessary data for authentication is right inside the token. A JWT consists of three key parts:

Header:

Specifies the token type and the hashing algorithm used (e.g., HMAC SHA256).
Payload:

Contains the claims—statements about an entity (usually the user) such as their ID, email, and roles. These claims are essential for both authentication and authorization.
Signature:

Ensures that the token hasn’t been tampered with. It’s created using the header, payload, and a secret key.

You can explore JWTs and see their inner workings at jwt.io 🔗.

How Does the Authentication & Authorization Process Work? 🛡️

When a client sends a request to a secure API, here’s what happens behind the scenes:

Client Request:

The client sends a request including the JWT in the Authorization header.
Authentication:
- The ASP.NET authentication provider extracts the JWT.
- It validates the token’s signature, expiration, and issuer.
- If valid, the user is authenticated.
Authorization:
- The server checks if the user has the required claims to access the resource.
- If the claims match the required policy, access is granted; otherwise, a 403 Forbidden error is returned.

Policy-Based vs. Role-Based Access Control 🔐

Role-Based Access Control (RBAC)

RBAC assigns roles directly to users.
For example, only users with an Admin role might access certain endpoints.
This method can become unwieldy as your user base grows.

Policy-Based Access Control

Policy-Based access control defines policies (like CanRead) that are assigned to roles.
When a user’s role changes, their permissions update automatically without modifying each user individually.
This approach is more flexible and scalable, especially for larger applications.

In our demo, we focus on policy-based access control for that extra bit of flexibility!

Implementing JWT in ASP.NET Core: A Step-by-Step Guide 💻

Let’s walk through how to set up JWT authentication in an ASP.NET Core application.

Clone the project

Clone the project from Github and take a look at the authentication and authorisation configuration in the DependencyInjection.cs file:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer();
        services.AddAuthorization();
        services.AddSingleton<IAuthorizationHandler, PermissionAuthorizationHandler>();
        services.AddSingleton<IAuthorizationPolicyProvider, PermissionAuthorizationPolicyProvider>();

We have all authentication configuration in the JwtBearerOptionsSetup file:

internal class JwtBearerOptionsSetup(IOptions<JwtOptions> jwtOptions): IPostConfigureOptions<JwtBearerOptions>
{
    private readonly JwtOptions _jwtOptions = jwtOptions.Value;

    public void PostConfigure(string? name, JwtBearerOptions options)
    {
        options.RequireHttpsMetadata = false;
        options.SaveToken = true;
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = _jwtOptions.Issuer,
            ValidateAudience = true,
            ValidAudience = _jwtOptions.Audience,
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_jwtOptions.SecretKey)),
            ValidateLifetime = true,
            ClockSkew = TimeSpan.Zero
        };
    }
}

This setup ensures that every token is validated against your issuer, audience, and signing key.

To add permission authorisation, we have added two files PermissionAuthorizationHandler and PermissionAuthorizationPolicyProvider.

In the PermissionAuthorizationHandler we make sure that the request has enough permission:

public class PermissionAuthorizationHandler : AuthorizationHandler<PermissionRequirement>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, PermissionRequirement requirement)
    {
        HashSet<string> permissions = context
            .User
            .Claims
            .Where(x => x.Type == Constants.Claims.Permissions)
            .Select(x => x.Value)
            .ToHashSet();

        if (permissions.Contains(requirement.Permission))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }
}

Now, only requests with a valid JWT will be able to access these endpoints.

Another important file is JwtProvider which is responsible for creating the JWT token:

public sealed class JwtProvider(IOptions<JwtOptions> jwtOptions, IPermissionService permissionService) : IJwtProvider
{
    private readonly JwtOptions _jwtOptions = jwtOptions.Value;

    public async Task<string> GenerateJwtTokenAsync(User user)
    {
        List<Claim> claims =
        [
            new(JwtRegisteredClaimNames.Sub, user.Id.ToString()),
            new(JwtRegisteredClaimNames.Email, user.Email!),
            new(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString())
        ];

        HashSet<string> permissions = await permissionService.GetPermissionsAsync(user.Id);

        claims.AddRange(permissions.Select(permission => new Claim(Constants.Claims.Permissions, permission)));

        SigningCredentials signingCredentials =
            new(new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_jwtOptions.SecretKey)), SecurityAlgorithms.HmacSha256);

        JwtSecurityToken token = new(_jwtOptions.Issuer, _jwtOptions.Audience, claims,
            expires: DateTime.UtcNow.AddMinutes(_jwtOptions.TimeoutMinutes), signingCredentials: signingCredentials);

        return new JwtSecurityTokenHandler().WriteToken(token);
    }
}

That's all the configuration we need to know about JWT authentication and authorisation.

Wrap-Up & Key Takeaways 📝

Today, we explored:

JWT Fundamentals:

Understanding JWT as a secure, compact way to transfer claims between parties.
Authentication & Authorization Flow:

From initial user login to token validation and access control.
Policy-Based Access Control:

Offering flexibility over traditional role-based approaches by defining policies like CanRead that are associated with roles.
Implementation in ASP.NET Core:

A step-by-step guide including configuration, creating a login endpoint, and securing your APIs with JWT.

Implementing JWT in your ASP.NET Core applications not only simplifies authentication but also scales beautifully with your growing user base. If you have any questions or feedback, feel free to drop a comment below!

Happy coding! 💻✨

🚀Clean Architecture in .NET

Mo — Tue, 11 Feb 2025 15:51:35 +0000

Introduction

Hello, fellow developers! 👋 Hope you’re doing well.

In the world of software architecture, structuring our code properly is crucial for maintainability, scalability, and testability. In our last discussion, we explored different architectural patterns, including Hexagonal Architecture, Layered Architecture, Onion Architecture, and Clean Architecture.

Today, we’re going to dive deep into Clean Architecture, what it is, why it matters, and how we can implement it in a real-world .NET application. 💡

The full source code is available on GitHub, so feel free to download it and follow along! 🛠️

What is Clean Architecture? 🤔

Clean Architecture, introduced by Uncle Bob (Robert C. Martin), is a domain-centric approach that helps us build software that is:

✅ Flexible – Easy to swap technologies (databases, frameworks, UI).

✅ Maintainable – Well-structured code with minimal dependencies.

✅ Testable – Business logic remains independent of external concerns.

Layer Breakdown 🏗️

Clean Architecture is structured into four key layers:

1️⃣ Domain Layer (Core Business Logic) – Contains entities, value objects, and domain services.

2️⃣ Application Layer (Use Cases & CQRS) – Defines business rules, CQRS commands/queries, and interfaces.

3️⃣ Infrastructure Layer (Implementations & DB Access) – Implements interfaces from the Application Layer.

4️⃣ Presentation Layer (API/UI Controllers) – Exposes the functionality via endpoints or UI.

At its core, Clean Architecture follows the Dependency Rule:

Inner layers should not depend on outer layers.

This means that business logic is independent of frameworks, databases, and UI technologies. 🚀

Implementing Clean Architecture in .NET 🏗️

Let’s break down how we’ve structured a .NET application using Clean Architecture principles.

1️⃣ Domain Layer – The Heart of Clean Architecture

The Domain Layer is the most important part of Clean Architecture. It contains:

✅ Entities (Book, Person) – Define core data structures.

✅ Value Objects (Genre, Address) – Immutable objects with validation.

✅ BaseEntity & BaseAuditableEntity – Common properties like Id, CreatedDate, UpdatedDate.

✅ Domain Exceptions (UnsupportedGenreException) – Custom exceptions for domain-level errors.

✅ Domain Events – Handling important business events.

A key decision here:

📌 Using DateTimeOffset instead of DateTime ensures proper time zone handling across different regions.

👉 The Domain Layer has no dependencies on external frameworks or databases, keeping it pure and reusable.

2️⃣ Application Layer – Business Logic & CQRS

The Application Layer is where we define use cases and business rules. It consists of:

✅ CQRS (Command Query Responsibility Segregation) – Separating read and write operations.

✅ Interfaces (e.g., IEmailService) – Abstractions for external dependencies.

✅ Command Handlers (CreateBookCommandHandler, DeleteBookCommandHandler).

✅ Validation Rules – Using FluentValidation to enforce constraints.

✅ Unit of Work Pattern – Ensuring atomic transactions.

📌 Key concept:

Commands modify data (CreateBookCommand, UpdateBookCommand).
Queries retrieve data (GetBookByIdQuery).
The Application Layer only contains interfaces, keeping it decoupled from the infrastructure.

3️⃣ Infrastructure Layer – Implementation Details

The Infrastructure Layer provides concrete implementations of the interfaces defined in the Application Layer. It includes:

✅ Entity Framework Core (EF Core) Configuration – Setting up database persistence.

✅ ApplicationDbContext – The actual database context.

✅ Unit of Work Implementation – Managing transactions efficiently.

✅ Email Service Implementation – Sending emails using external services.

✅ Global Exception Handling – Standardizing error responses.

📌 Infrastructure should depend on Application, not the other way around. This keeps the core logic flexible while allowing technology choices to change without affecting the domain.

4️⃣ Presentation Layer – Exposing APIs & Dependency Injection

The Presentation Layer (CleanArchitecture.API) is the entry point of the application, responsible for:

✅ API Controllers – Handling requests and responses.

✅ Swagger Documentation – Interactive API documentation.

✅ Dependency Injection (DI) Setup – Registering services.

✅ Global Exception Handling – Formatting errors consistently.

📌 In Program.cs, we wire everything together:

builder.Services.AddApplicationServices();  
builder.Services.AddInfrastructureServices();  
builder.Services.AddPresentationServices();

This ensures all dependencies are properly injected across the application.

Key Benefits of Clean Architecture 🏆

✅ Separation of Concerns – Code is modular and easier to maintain.

✅ Scalability – Easily swap out technologies without major refactoring.

✅ Testability – Business logic remains independent and can be tested in isolation.

✅ Flexibility – The application can evolve over time with minimal disruption.

By following this structure, we ensure our .NET applications are robust, maintainable, and scalable. 🚀

Wrapping Up & Next Steps

That’s a complete walkthrough of Clean Architecture in .NET! 🎉

💡 What’s Next?

🔥 Download the source code from my GitHub repo and try it yourself!
👍 If you found this helpful, give it a star on GitHub!
📢 Have questions? Drop a comment below!
🔔 Subscribe for more .NET & Software Architecture content!

Thanks for reading, and happy coding! 🎯

Blue-Green Deployment with Azure

Mo — Wed, 22 Jan 2025 07:16:54 +0000

Hello, everyone! In this article, we’re diving into Blue-Green Deployment, a brilliant technique for rolling out updates without breaking a sweat—or your app.

Here’s what we’ll cover:

What is Blue-Green Deployment?
The Pros and Cons—because no approach is perfect.
When Should You Use It?
Step-by-Step Demo with Azure—complete with automation tips to make your life easier.

So, grab a cuppa ☕ and let’s get started! 🚀

What is Blue-Green Deployment? 🤔

Imagine you’ve got two versions of your application running—one is "Blue" (your live environment), and the other is "Green" (your shiny new version).

Instead of directly updating the live version and risking downtime, you deploy changes to the Green environment first. Once you’re sure everything’s working perfectly, you simply swap traffic from Blue to Green. Users won’t notice a thing—except the new features! 🎉

Think of it like swapping stage sets in a play between scenes—seamless and smooth. 🎭

The Pros and Cons 🛠️

Pros:

Zero Downtime: No 'under maintenance' messages—just uninterrupted service.
Easy Rollbacks: Found a bug? Flip back to Blue and fix it.
Production-like Testing: Test your new version in a real-world environment.
Better User Experience: Smooth updates = happy users.

Cons:

Higher Costs: You’re running two environments, which can double infrastructure costs.
Complex Setup: Managing two environments isn’t simple—it requires planning and good tools.
Data Synchronisation: Handling databases and real-time data can get tricky.
Testing Overheads: Blue and Green must be identical apart from the new features.

When Should You Use It? 🎯

Blue-Green Deployment shines when downtime isn’t an option—think e-commerce sites, banking systems, or services that need constant availability.

If you’re working on a smaller project or have a tight budget, the added complexity and cost might not be worth it.

Demo with Azure 🖥️

Let’s put theory into practice! I’ll guide you through setting up Blue-Green Deployment using Azure.

Step 1: Create a Web App 🌐

Set up a resource group called BlueGreenResource.
Create a web app named BlueGreenWebApp. Use .NET 8, deploy to UK South, and choose the Standard S1 pricing tier.
Disable App Insights (optional for simple setups).

Step 2: Publish the First Version ✅

Use Visual Studio to deploy your app to the live environment.
This is version 1, which users can now see. 🎉

Step 3: Add a Staging Slot 🛠️

Add a staging slot to your web app. It’ll have its own domain (e.g., staging.bluegreenwebapp.azurewebsites.net).
Publish version 2 to this staging slot. Users won’t see this version yet, but it’s ready for testing.

Step 4: Swap the Slots 🔄

Once QA approves, use the Swap button in Azure to swap the staging slot with the live slot. Now, users are on version 2! 🎊

Step 5: Clean Up 🧹

Delete the staging slot to save costs.

Automate the Process with Azure DevOps 🤖

To avoid manual effort, we’ll set up a CI/CD pipeline in Azure DevOps:

Build Pipeline (YAML File):

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'deploymentapp-artifact'

This pipeline triggers on changes to the master branch. It builds the app, restores NuGet packages, and creates deployment artifacts.

Release Pipeline:

Create a Staging Slot: Use this script:

   az webapp deployment slot create --name $(webAppName) --resource-group $(resourceGroupName) --slot $(slotName)

Deploy to Staging:

Set the staging slot as the target in the pipeline.
Swap Slots:

Use the Azure App Service Manage task to swap environments.
Delete Staging Slot:

Clean up with this script:

   az webapp deployment slot delete --name $(webAppName) --resource-group $(resourceGroupName) --slot $(slotName)

Testing the Setup 🚀

Push changes to the master branch, and watch the magic happen:

Build triggers automatically.
Deployment to the staging slot occurs.
QA approves the changes.
Slots are swapped, and the staging slot is deleted.

Final Thoughts 💡

Blue-Green Deployment makes updates safer, faster, and smoother, especially for critical systems. While it’s not without challenges, automation tools like Azure DevOps make it easier to manage.

Have you tried Blue-Green Deployment? Share your experiences in the comments! 👇 Don’t forget to like, share, and bookmark this article for future reference. 😊

DEV Community: Mo

8 Filler Phrases That Quietly Weaken Your CV (And the Stronger Lines to Replace Them)

Why filler creeps in

The 8 phrases

1. "Responsible for…"

2. "Worked on…"

3. "Helped with…"

4. "Team player"

5. "Results-driven" / "Results-oriented"

6. "Excellent communication skills"

7. "Passionate about technology"

8. "Various" / "Multiple" / "A range of"

The rule underneath all eight

How CVSet applies this

Step 1 — Analyse

Step 2 — Optimise

Step 3 — Tailor

Step 4 — Skill Gap Analysis

What we got wrong first

Try this in ten minutes

Key Takeaways

Over to you

What an ATS Actually Does With Your CV (And How to Stay Visible)

Stage 1: Parsing — the machine reads your file first

Stage 2: Ranking — keyword matching, not judgement

Stage 3: Filtering — a human still decides

How we built CVSet around these three stages

1. Analyse — score the CV before anything is changed

2. Optimise — fix the structural problems

3. Tailor — match one CV to one job description

4. Application Pack — everything after the CV

5. AI Report — patterns across applications

What I learned building this

Key Takeaways

Over to you

Stop Rewriting Your CV: Tailor One Base CV for Every Job Application

TL;DR

The problem with "rewrite it for each job"

The rule we would not break: same facts, better visibility

Step 1 — Score the base CV first

Step 2 — Optimise once, not per job

Step 3 — Tailor against a real job description

Step 4 — Read the match score honestly

Key Takeaways

Your turn

Beyond Localhost: Implementing Production-Grade Entra ID Auth in .NET Aspire

The Identity Architecture: The "Three-Registration" Strategy

Step 1: Entra Portal Configuration

1. The API Registration

2. The React App Registration

3. The Scalar Registration

Step 2: Configuring the Frontend (Next.js & NextAuth)

Step 3: Wiring Up the .NET API

Why Scalar?

Step 4: The .NET Aspire Orchestration

Hard-Learned Lessons & Trade-offs

1. The Managed Identity Pivot

2. No CORS Nightmare (Thanks to the BFF Pattern)

3. Keycloak as a Fallback

Path to Production: azd up

Conclusion

Claude Opus 4.6 vs. GPT 5.4

Claude Opus 4.6 vs. GPT 5.4: My Take as a C#/.NET Dev on AI Coding Companions

The Setup: My C#/.NET AI Playground

GPT 5.4: The Speedy Generalist with a Few Surprises

Claude Opus 4.6: The Meticulous Architect, Slow and Steady

The Verdict: Don't Choose, Combine!

Your AI Pair Programming Partner(s)

C# Keeps Getting Better: My Favourite Modern Language Features

Streamlining Your Code: Less Ceremony, More Action!

Top-Level Statements: Kickstarting Your Apps

Global Using Directives: De-cluttering Your Files

Embracing Immutability: Records & init Setters

Record Types: The Data-First Class

init Setters: Immutable Properties, Flexible Creation

Smarter Decisions: Enhanced Pattern Matching

switch Expressions and Property Patterns

Wrapping Up

Migration from .NET 4.7 to .NET 10

Travels in Time:

Path to Production: `azd up`

Embracing Immutability: Records & `init` Setters

`init` Setters: Immutable Properties, Flexible Creation

`switch` Expressions and Property Patterns