C#-kod

När en .NET-lösning växer från ett fåtal mikrotjänster till tiotals eller hundratals projekt blir hanteringen av .csproj-filer snabbt en administrativ mardröm. Att manuellt synkronisera C#-versioner, kodanalysregler, säkerhetspolicyer och bygginställningar över hela kodbasen leder obönhörligen till “configuration drift” – där olika delar av systemet byggs med olika regler. Lösningen heter Directory.Build.props. Genom att placera denna fil i roten av ert repository importerar MSBuild automatiskt dess innehåll i samtliga underliggande projekt. Här är de viktigaste inställningarna du bör införa i Directory.Build.props för att säkra kodkvalitet, säkerhet och deterministiska byggen i en enterprisemiljö.

1. Kodkvalitet utan kompromisser

I stora team räcker det inte med skrivna riktlinjer för kodkvalitet; reglerna måste tvingas fram av kompilatorn. Genom att centralisera kodanalysen i MSBuild säkerställer ni att alla utvecklare och byggservrar arbetar mot exakt samma standard.

<PropertyGroup>
  <Nullable>enable</Nullable>
  <ImplicitUsings>enable</ImplicitUsings>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisLevel>latest-recommended</AnalysisLevel>
</PropertyGroup>

• TreatWarningsAsErrors: Förvandlar kompilatorvarningar till hårda fel. Detta förhindrar att teamet drabbas av “varningströtthet” där varningar ignoreras tills de hopar sig.
• EnforceCodeStyleInBuild: Gör att regler definierade i er .editorconfig valideras direkt under kompileringen och inte bara som visuella vinkar i IDE-miljön.
• AnalysisLevel: Aktiverar automatiskt de senaste rekommenderade Roslyn-analysatorerna för er installerade SDK-version. 🔗 Läs mer: Microsoft Learn: MSBuild Code Analysis Properties

2. Automatisk säkerhetsaudit av NuGet-beroenden

Sårbarheter i tredjepartsbibliotek (Supply Chain Attacks) är ett av de största hoten mot modern programvara. Från och med .NET 8/9 har .NET SDK inbyggt stöd för att granska NuGet-paket mot kända CVE-databaser under sjäva byggskedet.

<PropertyGroup>
  <NuGetAudit>true</NuGetAudit>
  <NuGetAuditMode>all</NuGetAuditMode>
  <NuGetAuditLevel>low</NuGetAuditLevel>
</PropertyGroup>

• NuGetAuditMode = all: Standardinställningen kollar enbart direkt importerade paket. Genom att sätta all tvingar du MSBuild att även granska alla transitiva beroenden (paket som dina direktimporterade paket i sin tur drar in).
• NuGetAuditLevel = low: Avbryter bygget (om TreatWarningsAsErrors är aktiverat) så fort en känd sårbarhet på nivå low eller högre upptäcks. 🔗 Läs mer: Microsoft Learn: Auditing package dependencies

3. Deterministiska byggen och maskering av källkodssökvägar

I en CI/CD-pipeline vill du uppnå två saker:

• Identiska binärer: Samma källkod ska ge exakt samma byte-för-byte-output oavsett vilken agent som bygger den.
• Säkerhet & Renhet: Absoluta sökvägar från byggagenten (t.ex. D:\a\1\s\src...) ska inte läcka ut i publicerade binärer, PDB-filer eller stack traces. ```xml

 * Deterministic: Tar bort maskinspecifik data som tidsstämplar och slumpmässiga GUID:er från kompileringen.
 * ContinuousIntegrationBuild: Mappar om alla absoluta filvägar på byggagenten till strukturerade, relativa sökvägar (t.ex. /_/src/Program.cs). Genom att villkorstyra detta mot miljövariabler som TF_BUILD (Azure DevOps) eller GITHUB_ACTIONS bevaras de vanliga lokala sökvägarna på utvecklarnas datorer så att lokal debugging fungerar smidigt.
🔗 Läs mer: Microsoft Learn: C# Compiler Options for Deterministic Builds

## 4. Renare projektstruktur med .NET Artifacts Output
Klassiska .NET-lösningar skräpar ner kodbasen genom att skapa bin/ och obj/ i varje enskilt underprojekt. För stora lösningar försvårar detta städning, git-hantering och CI-skript.
```xml
<PropertyGroup>
  <UseArtifactsOutput>true</UseArtifactsOutput>
</PropertyGroup>

Med UseArtifactsOutput aktiverat samlas all bygg-output i en gemensam struktur i lösningens rot: ./artifacts/bin/, ./artifacts/obj/ och ./artifacts/package/. Detta gör det extremt enkelt i t.ex. Azure Pipelines att peka ut var artefakter och testresultat finns utan att behöva söka igenom hela trädstrukturen. 🔗 Läs mer: Microsoft Learn: Artifacts output layout

5. SourceLink: Sömlös felsökning av interna NuGet-paket

Om företaget delar källkod internt via egna NuGet-paket drabbas utvecklare ofta av mardrömmen att inte kunna stega sig in i kod som ligger i ett internt bibliotek. SourceLink löser detta genom att bädda in kopplingar till er Git-repository direkt i symbolfilerna (.snupkg).

<PropertyGroup>
  <PublishRepositoryUrl>true</PublishRepositoryUrl>
  <EmbedUntrackedSources>true</EmbedUntrackedSources>
  <IncludeSymbols>true</IncludeSymbols>
  <SymbolPackageFormat>snupkg</SymbolPackageFormat>
</PropertyGroup>

Detta gör att Visual Studio och Rider automatiskt kan hämta exakt rätt version av källkodsfilen från Azure Repos eller GitHub när en utvecklare “stegade in” (F11) i en metod från ert interna NuGet-paket. 🔗 Läs mer: Microsoft Learn: SourceLink Overview Den kompletta Enterprise-mallen Skapa filen Directory.Build.props i källkodens rotmapp (bredvid er .sln-fil) och klistra in följande basmönster:

<Project>
  <PropertyGroup>
    <!-- Språk & Grundinställningar -->
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    
    <!-- Kodkvalitet & Analys -->
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
    <AnalysisLevel>latest-recommended</AnalysisLevel>

    <!-- Säkerhetsgranskning av NuGet-beroenden -->
    <NuGetAudit>true</NuGetAudit>
    <NuGetAuditMode>all</NuGetAuditMode>
    <NuGetAuditLevel>low</NuGetAuditLevel>

    <!-- Centraliserad bygg-output -->
    <UseArtifactsOutput>true</UseArtifactsOutput>

    <!-- Deterministiska byggen & Maskering av agent-sökvägar -->
    <Deterministic>true</Deterministic>
    <ContinuousIntegrationBuild Condition="'$(TF_BUILD)' == 'true' OR '$(GITHUB_ACTIONS)' == 'true'">true</ContinuousIntegrationBuild>

    <!-- SourceLink & Symboler -->
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>

    <!-- Företagsmetadata -->
    <Company>Ditt Företag AB</Company>
    <Copyright>Copyright © Ditt Företag AB $([System.DateTime]::Now.Year)</Copyright>
  </PropertyGroup>
</Project>

Att införa Directory.Build.props på detta sätt flyttar tyngdpunkten från reaktiv rensning av teknisk skuld till automatisk, proaktiv kvalitetssäkring. Det ger ett tryggare flöde från den lokala utvecklingsmaskinen hela vägen ut till produktionssatta container-avbildningar och serverlösa funktioner.

Säkerhet i moderna webbapplikationer handlar sällan om en enskild “silverkula”. Det handlar om Defense in Depth – att bygga överlappande säkerhetsskikt så att om ett lagers skydd brister, står nästa redo att stoppa angriparen.

I och med releasen av .NET 10 har Microsoft introducerat flera nya funktioner för autentisering, prestanda och telemetri som gör det enklare än någonsin att bygga extremt säkra applikationer – om man konfigurerar dem rätt.

I denna guide går vi igenom hur du härdar (hardens) din Blazor-, MVC- eller Web API-applikation i .NET 10 från grunden till avancerad nivå.

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.

Att kliva från en .NET 8-applikation – speciellt en som bär på legacy-bagage – direkt till .NET 10 är ett fantastiskt tillfälle att inte bara lyfta ramverket, utan att faktiskt städa bort teknisk skuld. För att göra kodbasen mer lätthanterlig, enhetlig och framtidssäker bör fokus ligga på att centralisera inställningar, utnyttja kompilatorn hårdare och implementera moderna arkitekturmönster.

I den här artikeln går vi igenom hur du sätter upp en modern, strömlinjeformad projektstruktur från grunden med hjälp av det nya .slnx-formatet, global.json, Directory.Build.props, och Central Package Management (CPM med Directory.Packages.props).

För oss som bygger moderna .NET-lösningar – kanske med en Vertical Slice-arkitektur och med siktet inställt på .NET 10 – är smidiga CI/CD-flöden helt avgörande. Ett historiskt smärtområde i våra Azure DevOps-pipelines har varit databasprojekten. Klassiska SQL Server Data Tools (SSDT) .sqlproj-filer är ökända för att skapa enorma merge-konflikter eftersom varje enskild fil måste registreras i en gigantisk XML-struktur [1].

Lösningen stavas SDK-style SQL-projekt. Genom att använda Microsofts SDK Microsoft.Build.Sql får vi minimala projektfiler, wildcard-inkludering av skript och fullt plattformsoberoende kompilering via kommandoraden.

Här är en komplett guide till hur du migrerar dina gamla databasprojekt till det moderna formatet, hur filstrukturen bör se ut och en viktig varning gällande stödet i Visual Studio 2026.

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?

För att räkna ut hur många unika värden som finns i en lista med hjälp av LINQ i C#, så kan du använda metoden .Distinct().

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.

Här är ett enkelt sätt att jämföra två listor med varandra för att se vilka objekt som saknas i ena eller andra listan: