[JsonDerivedType(typeof(HockeyPlayer), 0)]
[JsonDerivedType(typeof(FootballPlayer), 1)]
[JsonDerivedType(typeof(BasketPlayer), 2)]
public class Player
{
    public string Name { get; set; }
    public string City { get; set; }
}
public class HockeyPlayer : Player

{

public int JerseyNumber { get; set; }

}
public class FootballPlayer : Player

{

public int JerseyNumber { get; set; }

public int ShoeSize { get; set; }

}
public class BasketPlayer : Player

{

public int LengthInCentimeter { get; set; }

}
public class DemoJson

{

public void Run()

{

var players = new List

{

new BasketPlayer { City = "Stockholm", Name = "Stefan", LengthInCentimeter = 190 },

new HockeyPlayer() { City = "Colorado", Name = "Foppa", JerseyNumber = 21 },

new FootballPlayer() { City = "Stockholm", Name = "Brollan", JerseyNumber = 9, ShoeSize = 42},

};

var json = JsonSerializer.Serialize(players);
    var l = JsonSerializer.Deserialize<List<Player>>(json);
    foreach(var p in l)
        Console.WriteLine(l);
}

}

[{"$type":2,"LengthInCentimeter":190,"Name":"Stefan","City":"Stockholm"},{"$type":0,"JerseyNumber":21,"Name":"Foppa","City":"Colorado"},{"$type":1,"JerseyNumber":9,"ShoeSize":42,"Name":"Brollan","City":"Stockholm"}] 

var json = JsonConvert.SerializeObject(players, Formatting.Indented, new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.All
}

static T Add(T left, T right)
    where T : INumber
{
    return left + right;
}

ASP.NET Core:

Nullable models in MVC Views and Razor Pages

@model Product?

aldrig haft problem med detta

Minimal APIs

Klart förbättrat gällande filters etc etc

Jag ser inte poängen med minmal API:s överhuvudtaget. "Härma" django/expressjs/etc var väl hur det började och det är inte DÄR programmeringskomplexiteten ligger. I vårt dagliga arbete menar jag.

SignalR

har nu Dependency injection för Hub constructorn. Visst jättebra...men en ganska smal sak

Blazor

ja....massa nya saker där men det är ju för att produkten i sig är ung och inte speciellt feature-rich som den är nu. Jag avvaktar...vill nog se att Blazor lyfter...

HTTP/2 performance improvements

nu pratar vi nörderi. Kestral (den inbyggda http-servern som används i våra webbapplikationer) har förbättrat throughput för multiplexade connections (förenklat tänk dig ett anrop till en html-sida - den kommer ju sannolikt att göra många anrop till samma server: för att hämta css/images etc etc)

Inget jag testat att det verkligen gör skillnad, men bara genom att läsa att man ändrat från locks (motsvarande "critical sections") till en kö gör att man förstår att CPU resurser kommmer slösas i mindre utsträckning

C# 11

Generic attributes.

Alla "whats new" sajter har med detta. Fast ingen kan visa på ett vettigt use-case...Stefan is NOT interested

Raw string literals

Också med på alla... just detta exempel

string longMessage = """
    This is a long message.
    It has several lines.
        Some are indented
                more than others.
    Some should start at the first column.
    Some have "quoted text" in them.
    """;

Jaha...

Required member

public class BasketPlayer : Player
{
    public int LengthInCentimeter { get; set; }
    public required string Position { get; set; }
}

Nu kan du inte

            new BasketPlayer { City = "Stockholm", Name = "Stefan", LengthInCentimeter = 190 },

Utan den säger

Error	CS9035	Required member 'BasketPlayer.Position' must be set in the object initializer or attribute constructor.	

I LOVE IT !!!! Jag som utbildare förespråkar ju proper use av constructors, alltid säkerställa valid state. Men object initializer vill man ju ofta köra

File scopade data types

// In File1.cs:
file class HiddenWidget
{
    public int Work() => 42;
}

Jag gillar tänket kring module-scopes osv som man ser i Python och Go. Men vet ännu inte om jag egentligen behöver det. Kodgeneratorer nämns ju som ett självklar usecase där man enkelt undviker name collisions

LIST Patterns

Jag kommer här bara visa och prata om jämförelser

    int[] nummer = { 1, 2, 3, 5 };
    if (nummer is [_, _, 3, _]) //2 whatever, sen en trea sen en   whatever
    {
        Console.WriteLine("Samma");
    }

    if (nummer is [.., 5])  // SLUTAR MED EN FEMMA
    {
        Console.WriteLine("Samma");
    }

Gillar jag detta? Vet inte...Här har vi återigen en sån sak som kommer att göra att kodbaserna ute på företagen kommer se mer och mer olika ut. Standards, konsekvent syntax. Såna saker (som gör att det är "enkelt" för nya att komma in och koda) värderar företagen mer än cool kod.

Herregud vad är fel på:

        if (nummer.Length == 4 && nummer[2] == 3)
        if (nummer.Length  >= 1 && nummer[nummer.Length-1] == 5)

Ska jag uppgradera?

Ja. Vare sig "behöver" nya features eller inte så är det ju det bara att åka med. Vi vill absolut inte stå med applikationer byggda med ett ramverk som inte längre stödjs (tex pre Core 3.1 just nu då)

Är det stora saker som behöver göras? Sannolikt inte men kolla in Breaking changes https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0

Vart är vi på väg, Stefans rants:

Jag låter nog som en gammal gubbe, och det tar jag varje dag i veckan. Ute på företag tar jag gärna rollen som den konservative - jag älskar cool teknik, det är inte det - men en stor del i vårt uppdrag är just att säkerställa modifierbar/konsekvent kod i hela applikationens livscykel.

Det är lätt att bli carried away och betrakta sin kod som något mer än vad det är. Det kan visst vara vackert, det kan vara poesi.

Min kod är det. Eller jag försöker skapa poesi med min kod

Men kod som inte är min - dvs FÖRETAGETS gäller att

• nåt som ska fungera och skapa affärsvärden för ditt företag
• och det ska gå att förändra applikationen i framtiden
• företagets framtida kompetensförsörjning är ju en faktor att ha med

Jag har lite svårt för många av nyheterna här: det Microsoft gör (enligt mig) är att man lyssnar FÖR MYCKET (är det möjligt?) på communityt. Visst ska man lyssna, men med en uttalad plan för C# att den som programmerar C# ska behöva "skriva så få rader som möjligt" (yes, jag läser det på jättemånga microsoft-bloggar just nu angående csharp 11) så tycker jag man siktar fel. Andra språk har som mål att "det ska bara finnas ETT sätt att göra saker på" (Go) eller att verkligen vara slow moving för Enterprise-företag ska kunna ha långsiktighet i kunskapsförsörjning etc (Java)

Det Microsoft riskerar vara på väg emot är ytterligare en BLOAT-återvändsgränd som med .NET Framework och en total omskrivning inom...ja who knows?