.NET

I en växande mikrotjänstarkitektur eller en organisation med tiotals olika applikationer blir felhantering snabbt vilda västern. Ett team returnerar råa strängar, ett annat kastar generiska 500 Internal Server Error för valideringsfel, och ett tredje uppfinner sitt eget slutpunktformat. När arkitekturen växer till ett 20-tal appar med hundratals unika interna felkoder blir bristen på enhetlighet en ren mardröm för både frontend-utvecklare och supporttekniker.

Lösningen är inte att tvinga alla utvecklare att skriva hundratals rader repetitiv try-catch-logik. Svaret är att centralisera arkitekturen i ett internt, delat NuGet-bibliotek.

Här är en ritning för hur du bygger ett enhetligt, utökbart och säkert felhanteringsbibliotek baserat på modern .NET-arkitektur.

Tänk dig att du leder en organisation med ett 20-tal olika applikationer och mikrotjänster. Du vill ha perfekt observerbarhet – strukturerad JSON-loggning, distribuerad spårning (Distributed Tracing) och prestandamätetal (Metrics). Men du vill inte tvinga varje enskilt produktteam att bli experter på OpenTelemetry-arkitektur, Serilog-konfiguration eller DevOps-pipelines.

Lösningen? Du bygger ett internt NuGet-paket (t.ex. Company.Telemetry) som paketerar organisationens best practices. Det bästa av allt? Genom att hålla oss strikt till .NET-standarder som ILogger och Activity kan produktteamen logga precis som vanligt, medan vårt paket sköter magin under huven – oavsett om de kör lokalt med .NET Aspire eller i produktion mot en central OpenTelemetry Collector.

I den här bloggposten går vi igenom exakt hur du bygger detta paket.

Att bygga distribuerade system och mikrotjänster utan ordentlig insyn är som att köra bil med förbundna ögon. När något går fel vill du inte leta febrilt i isolerade textfiler på fem olika servrar. Du vill ha en sammanhängande berättelse som visar vem som gjorde anropet, vad som hände och varför det tog tid.

I .NET 10 är OpenTelemetry (OTel) den absoluta guldstandarden för detta. Det är en öppen, leverantörsoberoende standard som gör att du kan samla in Traces (spår), Logs (loggar) och Metrics (mätvärden) utan att låsa upp dig till specifika plattformar som Datadog eller Dynatrace.

I den här guiden bygger vi en komplett, produktionsredo observerbarhetspipeline i .NET 10 – från grundläggande arkitektur till smarta enrichers. När vi är klara är din applikation helt redo att sömlöst pluggas rakt in i verktyg som .NET Aspire Dashboard.

Att migrera en ASP.NET MVC-applikation från gamla .NET Framework 4.8 till det moderna .NET 10 är inte bara en uppgradering – det är ett generationsskifte. Du lämnar det tunga, Windows-bundna IIS-ekosystemet och kliver in i en värld av blixtsnabb prestanda, plattformsoberoende och otroligt ren kod.

Det är sällan en “sök och ersätt”-manöver. För att få ut maximalt av .NET 10 behöver du tänka om kring hur applikationen startar, hur filer hanteras och, framför allt, hur du strukturerar din kod.

Här är en guiden (med kod, arkitekturtips och referenser) för att göra resan smidig och resultatet uppdelat enligt vertikala slices.

Att bygga e-tjänster och flerstegsflöden (wizards) i ASP.NET Core MVC är en vanlig uppgift i företagsapplikationer. Men när ett flöde växer från tre till tio steg blir det snabbt en utmaning att hålla ordning på vyer, specifika valideringsmodeller och tillståndshantering (state management). Om allt sprids ut i generiska mappar tappar utvecklare snabbt överblicken.

Genom att kombinera principer från Vertical Slice Architecture med en strikt sekventiell namngivningsstandard och en robust distribuerad sessionsarkitektur, kan vi skapa en struktur som är självförklarande, högpresterande, extremt underhållsvänlig och redo för produktion i molnet.

När du kliver in i modern webbutveckling med .NET 10 och ASP.NET Core MVC är det en specifik rad i din _ViewImports.cshtml-fil som lägger fundamentet för hela din frontend-arkitektur:

@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

Kort sagt är detta startskottet som aktiverar Tag Helpers i dina Razor-vyer. Utan den raden är alla dina smarta HTML-taggar (som <a asp-action="..."> eller <form asp-controller="...">) bara död text som servern ignorerar.

I den här djupdykningen ska vi titta närmare på hur Tag Helpers fungerar under huven, hur du härdar dina applikationer med Anti-Forgery Tokens, och hur du undviker det klassiska produktionsfelet där användare kastas ut ur formulär vid serveromstarter.

Att hantera konfiguration i ett modernt enterprise-system handlar om betydligt mer än att bara läsa en sträng från appsettings.json. I storskaliga system – som ofta bygger på arkitekturer som Vertical Slice Architecture, distribuerade mikrotjänster och molnbaserad infrastruktur – blir hanteringen av inställningningarnas livscykel (lifetime) helt kritisk.

Om du injicerar fel typ av Options-gränssnitt riskerar du allt från subtila buggar med datakonsistens under en HTTP-request, till applikationskrascher på grund av Captive Dependencies (fångade beroenden).

I .NET 10 har vi tre primära verktyg för att läsa konfiguration: IOptions<T>, IOptionsSnapshot<T> och IOptionsMonitor<T>. Låt oss gå till botten med exakt hur de fungerar, hur de presterar under huven och hur du väljer rätt i din arkitektur.

I den moderna DevOps-världen räcker det inte längre med att bara ha applikationskoden under versionshantering. Att klicka sig fram i grafiska gränssnitt för att bygga bygg- och driftsättningsflöden – så kaldade Classic Release Pipelines – är ett föråldrat arbetssätt som skapar underhållsskulder, bristande spårbarhet och konfigurationsavvikelser (configuration drift).

För att bygga en riktigt skarp, robust och automatiserad release- och deploy-pipeline i Azure DevOps bör du helt överge det gamla grafiska gränssnittet och fullt ut satsa på YAML Multi-stage Pipelines.

Med detta tillvägagångssätt tillämpar du principerna för Pipeline as Code (PaC). Hela din CI/CD-arkitektur deklareras i en textfil som versionshanteras i ditt Git-repository, precis som din vanliga C#- eller .NET-kod. Det innebär kodgranskning (Pull Requests) för infrastrukturändringar, fullhistorik och enkel återställning.

I moderna, distribuerade system räcker det sällan med traditionell felloggning. När ett anrop från en användare studsar genom en API-gateway, två mikrotjänster och en databas, och något går fel – hur vet du var flaskhalsen eller kraschen uppstod?

Svaret är Observability (observerbarhet), och branschstandarden för detta är OpenTelemetry (OTel). I den här guiden ska vi bryta ner de centrala koncepten Traces och Spans, och titta på hur vi implementerar dem i .NET 10.

Det finns ett klassiskt ordspråk inom IT-världen: “Om det fungerar, rör det inte.” Men när vi pratar om publika webbtjänster och interna API:er som förväntas rulla stabilt, säkert och prestandalätt fram till år 2032, så håller inte det gamla tänket längre.

Står du inför valet att låta dina applikationer ligga kvar på det beprövade .NET Framework 4.8 eller att migrera till det moderna .NET 10? Det korta svaret är att det finns en inbyggd paradox mellan målet att minimera livscykelhantering (LCM) och målet att ha ett modernt, säkert system.

Här bryter vi ner varför steget till .NET 10 är helt rätt väg att gå – särskilt om du kör i en lokal on-prem-miljö med både Windows-servrar och containers.

Har du någon gång kliat dig i huvudet när pipelinen kraschar för att en .NET SDK saknas, eller funderat på om din app faktiskt kommer att starta på produktionsservern efter den senaste säkerhetspatchen?

Du är inte ensam. .NET-världen är full av versionsnummer: 10.0.106, 10.0.301, 10.0.108. Men sanningen är att .NET har ett väldigt smart (och ibland missförstått) system för att hålla isär byggtid och körtid.

Allt kokar ner till två filer: global.json och *.runtimeconfig.json. Låt oss reda ut vem som gör vad!

Har du någon gång tittat på versionsnumret för en .NET SDK och undrat varför det hoppar från 10.0.108 till 10.0.204 istället för att följa vanlig semantisk versionshantering (SemVer)?

Det är lätt att tro att det bara är slumpmässiga siffror, men sanningen är att de tre sista siffrorna i en .NET SDK-version döljer viktig information. Genom att förstå hur Microsoft paketerar sina utvecklingsverktyg kan du både säkra dina applikationer och förhindra att dina CI/CD-pipelines plötsligt går röda.

I det här inlägget reder vi ut begreppet Feature Bands och hur du bäst konfigurerar din global.json för en stabil och säker utvecklingsmiljö.

Om den första dagen på DevSum handlade mycket om djupgående kodstrukturer och .NET-specifika verktyg, lyfte dag två blicken mot de större och ibland mer obekväma sanningarna i vår bransch. Det blev en dag fylld av produktkritik, välbehövliga sanningar om hur vi spenderar vår tid och mycket handfasta strategier för att skriva tester som faktiskt gör nytta.

Här är min sammanfattning av de mest tankeväckande sessionerna från dag två!

Att kliva in på Kistamässan för årets upplaga av DevSum är alltid fyllt av förväntan. Det är en av de bästa platserna för oss utvecklare och arkitekter att tanka ny inspiration, diskutera utmaningar med kollegor i branschen och djupdyka i de senaste teknikerna. Årets schema gjorde mig inte besviken – det blev en intensiv resa som spände över allt från mental styrka och teamkultur till djupgående arkitekturmönster och avancerad testning i .NET.

Här är mina viktigaste lärdomar och reflektioner från en riktigt intressant dag!

Sitter er organisation fortfarande med system byggda på det klassiska .NET Framework (t.ex. version 4.8)? Ni är inte ensamma. Det har varit en otroligt stabil plattform som har tjänat företag väl i över ett decennium. Men tekniklandskapet har förändrats…

Detta är ett exklusivt bonusinlägg i min bloggserie "Historien om .NET". Efter att ha nått hela vägen fram till dagens nutid med .NET 10 igår, kan vi inte låta bli att vända blicken mot horisonten. Just nu pågår utvecklingen för fullt av .NET 11 och C# 15. I den här posten går vi igenom vad Microsoft hittills har släppt i sina tidiga Previews och vad vi kan förvänta oss av nästa stora plattformssteg.

Detta är det sjunde inlägget i min bloggserie om “Historien om .NET”. Idag har vi nått fram till den absoluta nutiden och kliver in i november 2025 då .NET 10 och C# 14 gjorde sin storslagna entré. Som en efterlängtad LTS-release (Long Term Support) cementerade den plattformens mognad och gav mjukvaruarkitekter verktygen som krävs för att tygla storskaliga mikrotjänststrukturer och monorepos med järnhand.

Detta är sjätte inlägget i min bloggserie om “Historien om .NET”. Idag kliver vi in i november 2024 då .NET 9 och C# 13 släpptes lös. Som en funktionsrik STS-version (Standard-Term Support) tog Microsoft plattformen rakt in i AI-eran, samtidigt som de revolutionerade hur vi hanterar distribuerad data med det nya HybridCache-systemet. Fokus på smartare trådsäkerhet, molnoptimering och efterlängtad kodsyntax.

Detta är femte inlägget i min bloggserie om “Historien om .NET”. Idag spolar vi fram till november 2023 då .NET 8 och C# 12 dundrade in på scenen. Som en stabil LTS-release (Long Term Support) knöt den ihop säcken för Microsofts vision om en modern, plattformsoberoende miljö och introducerade funktioner som gjorde plattformen redo för framtidens molnarkitekturer och AI. Fokus på “Cloud Native”, fullfjädrad Blazor och efterlängtad kodsyntax.

Detta är fjärde inlägget i min bloggserie om “Historien om .NET”. Idag tar vi steget in i november 2022 då .NET 7 och C# 11 släpptes. Även om det var en STS-version (Short Term Support), blev det en av de mest innovationsrika releaserna där Microsoft banade väg för molnbaserad mikroprestanda med Native AOT och inbyggda Enterprise-verktyg.

Detta är tredje inlägget i min blogg serie om “Historien om .NET”. Här går vi in på nyheternba i moderna .NET6.0 och C# 10, som släpptes noveber 2021. En enorm prestandabomb till LTS-version som revolutionerade webbutvecklingen genom introduktionen av Minimala API:er.

Detta är andra inlägget i min blogg serie om “Historien om .NET”. Vi hoppar dock över de tidigaste skedena av .NET Framework och .NET Core, de kan du läsa om i första bloggposten. Istället så hoppar vi rakt in i den moderna .NET5.0 och C# 9. Det var här den moderna dotNET (.NET) äntligen sammanfogade allt sedan november 2020.

Jag tänkte börja en liten blogg serie, om historian bakom det moderna dotNET (.NET). Vad var det som hände när man gick från den gamla “legacy” .NET Framework v1-v4 till en sväng förbi .NET Core v1-v3, vidare med den moderna .NET5 som sedan inkrementerat ett nummer varje år i november, till dagens .NET10. Där vi har landat idag (sedan 2025-11).

I en tid där cyberattacker allt oftare riktas mot mjukvarukedjan (Software Supply Chain) har begreppet SBOM (Software Bill of Materials) gått från att vara ett “bra att ha” till ett absolut krav. Att veta exakt vilka komponenter, öppna källkodspaket och beroenden din applikation består av är grundbulten i modern applikationssäkerhet.

I dagens landskap av “Supply Chain Security” är kraven på kontroll över tredjepartsberoenden högre än någonsin. Att veta exakt vilka paket dina applikationer använder – och om de innehåller kända säkerhetshål – är inte längre valfritt. Många företag betalar dyra licenser för tredjepartstjänster och API:er för att lösa detta.

Från flera röriga .NET 5-8 C#-projekt till en modern .NET 10-arkitektur.

Att hålla koll på livscykeln för sina servrar är en klassisk IT-utmaning. Windows Server styrs av Microsofts Fixed Lifecycle Policy, vilket innebär 10 års total support innan systemet når sitt End of Life (EOL) och kranen för säkerhetsuppdateringar stängs helt.

Inom modern .NET-utveckling är lösningen ofta ett dotnet add package bort. Det är fantastiskt för produktiviteten, men varje ny dependency är också ett långsiktigt åtagande.

Så frågan är inte “NuGet eller NoGet” som ett svartvitt val, utan hur vi gör medvetna val.

ASP.NET Core utvecklades som den moderna, öppna och plattformsoberoende efterföljaren till klassisk ASP.NET. Nu är det dags att agera för team som fortfarande använder ASP.NET Core 2.3.

Det var lördagen den 4 april 2026 – dagen innan påskdagen – och vi hade besök hemma. Jag lade märke till hur min sambos systerdotter mest satt klistrad vid sin surfplatta, och då slog det mig plötsligt: varför inte kanalisera den där skärmtiden till något unikt? Varför inte bygga ett eget, litet påskspel till henne direkt på webben?

Här kommer en liten guide över hur man kan aktivera och installera IIS fjärr hanteraren via Windows 11.

Nu är äntligen .NET 10 här – släppt och live! 🎉 11 november 2025 släppte Microsoft den senaste LTS-versionen: .NET 10. Det här är en stor milstolpe för plattformen – en stabil, långsiktigt stödd bas för företag och projekt som vill ligga i framkant vad gäller prestanda, säkerhet och produktiv utvecklarupplevelse.

– från idé till komplett privatekonomi-app i .NET

Jag har länge velat ha ett verktyg som ger mig verklig kontroll över min privatekonomi – något som är snabbt, privat, körs lokalt eller i mitt eget moln och samtidigt är roligt att använda. Det blev startskottet för Privatekonomi: en Blazor Server-applikation med .NET 9, MudBlazor och .NET Aspire som orkestrerar alla tjänster. I den här bloggposten berättar jag hur jag byggde systemet på 1,5 vecka med GitHub copilot, vilka designval jag gjort och visar en massa skärmbilder.

En liten påminnelse om dotnet list package som är ett enkelt kommando man kan köra för att kolla om man är på senaste NuGet-paket versioner, är då att använda sig av:

Den 29 juli 2025 släpptes .NET Aspire 9.4 – den största uppdateringen hittills! Nu finns ett fristående CLI-verktyg (native AOT) som gör det enkelt att skapa, köra och konfigurera dina appar direkt från terminalen. Med kommandon som aspire new, aspire add, aspire run och aspire config blir utvecklingsflödet snabbare och smidigare.

Det senaste året har varit väldigt mycket pluggande och lära känna .NET och React.