Spcnet.it

2026-04-16 14:14:54

Confronto tra stringhe in C#: Equals, OrdinalIgnoreCase, StringComparer e le insidie culturali

Il confronto tra stringhe è una delle operazioni più comuni in qualsiasi applicazione .NET, eppure è anche una delle fonti più insidiose di bug difficili da riprodurre — specialmente quando l’applicazione viene eseguita in ambienti con culture diverse o in pipeline CI/CD con impostazioni locali variabili. In questo articolo vediamo come funzionano correttamente string.Equals(), OrdinalIgnoreCase, StringComparer e come evitare le trappole più comuni legate alla cultura.

L’operatore == e il confronto ordinale

L’operatore == su stringhe esegue un confronto ordinale case-sensitive, basato sui valori Unicode dei caratteri, senza alcuna considerazione culturale:

var a = "Hello";
var b = "hello";
Console.WriteLine(a == b);       // False
Console.WriteLine(a == "Hello"); // True

Questo è corretto e prevedibile per confronti interni al codice (chiavi di dizionari, nomi di variabili, costanti). Il problema nasce quando si vuole un confronto case-insensitive, o quando si confrontano stringhe con caratteri soggetti a regole culturali.

string.Equals() con StringComparison

La regola d’oro è: passare sempre esplicitamente un parametro StringComparison. Senza di esso, alcuni overload usano CurrentCulture, creando comportamenti potenzialmente incoerenti tra ambienti diversi.

// Confronto case-insensitive, senza dipendenze culturali
bool uguale = string.Equals("admin", input, StringComparison.OrdinalIgnoreCase);

// Equivalente con metodo d'istanza
bool ancheUguale = "admin".Equals(input, StringComparison.OrdinalIgnoreCase);

Panoramica dei valori di StringComparison

Valore	Case	Cultura	Uso consigliato
Ordinal	Sensibile	Nessuna	File, chiavi, dati binari
OrdinalIgnoreCase	Insensibile	Nessuna	Comandi, URL, identificatori
InvariantCulture	Sensibile	Invariante	Testo serializzato/persistito
InvariantCultureIgnoreCase	Insensibile	Invariante	Testo serializzato, case-indipendente
CurrentCulture	Sensibile	Locale utente	Testo mostrato all’utente
CurrentCultureIgnoreCase	Insensibile	Locale utente	Ricerca/filtro lato UI

La trappola di ToLower() e ToUpper()

Uno degli antipattern più diffusi è usare ToLower() per normalizzare le stringhe prima del confronto:

// Antipattern: alloca una nuova stringa inutilmente
if (input.ToLower() == "admin") { }
if (input.ToLowerInvariant() == "admin") { }

// Corretto: nessuna allocazione, semantica esplicita
if (string.Equals(input, "admin", StringComparison.OrdinalIgnoreCase)) { }

Il problema non è solo di prestazioni (allocazione di una stringa temporanea), ma di correttezza semantica. La versione con ToLower() dipende dalla cultura corrente del thread, mentre OrdinalIgnoreCase è culturalmente neutro e deterministico.

Il problema della “i” Turca

Questo è forse il bug più famoso legato alla cultura nelle stringhe. In turco esistono quattro varianti della lettera i: la “i” minuscola con punto diventa “İ” maiuscola con punto (non “I” come in italiano), e la “ı” minuscola senza punto diventa “I” maiuscola. Il risultato:

var culture = new System.Globalization.CultureInfo("tr-TR");

// Bug su locale turco!
bool sbagliato = "file".ToUpper(culture) == "FILE"; // False! "file" diventa "FİLE" in turco

// OrdinalIgnoreCase usa regole invarianti
bool corretto = string.Equals("file", "FILE", StringComparison.OrdinalIgnoreCase); // True

Questo bug si manifesta tipicamente in applicazioni multi-tenant o globali dove il server ha una cultura diversa dall’ambiente di sviluppo. La soluzione è sempre usare OrdinalIgnoreCase per confronti tecnici (nomi di file, comandi, URL, header HTTP) e riservare CurrentCulture solo al testo destinato all’utente finale.

StringComparer per collezioni

StringComparer implementa sia IComparer<string> che IEqualityComparer<string>, rendendolo ideale per strutture dati come Dictionary, HashSet e SortedSet:

Dizionario case-insensitive per gli header HTTP

// "Content-Type" e "content-type" devono essere equivalenti
var headers = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
headers["Content-Type"] = "application/json";

Console.WriteLine(headers["content-type"]); // application/json
Console.WriteLine(headers["CONTENT-TYPE"]); // application/json

SortedSet case-insensitive

var comandi = new SortedSet<string>(StringComparer.OrdinalIgnoreCase);
comandi.Add("Start");
comandi.Add("stop");

bool haStart = comandi.Contains("START"); // True
// I duplicati vengono rilevati correttamente
comandi.Add("START"); // Non aggiunge, esiste già come "Start"
Console.WriteLine(comandi.Count); // 2

Confronto ad alte prestazioni con Span<char>

Per scenari con requisiti di performance elevati (parsing di protocolli, hot paths), .NET offre confronti allocation-free tramite ReadOnlySpan<char>:

var riga = "Content-Type: application/json";

// Confronto senza allocare nuove stringhe
bool isContentType = riga.AsSpan(0, 12).Equals(
    "Content-Type".AsSpan(),
    StringComparison.OrdinalIgnoreCase);

// StartsWith su Span
bool isHttps = url.AsSpan().StartsWith(
    "https://".AsSpan(),
    StringComparison.OrdinalIgnoreCase);

Questo approccio è particolarmente utile in middleware HTTP, parser di configurazione e codice che elabora grandi volumi di testo.

Pattern Matching con Switch

Il pattern matching di C# non supporta nativamente il confronto case-insensitive negli switch, ma esistono due approcci corretti:

// Approccio 1: Guard clause con Equals
var risultato = comando switch
{
    _ when string.Equals(comando, "start", StringComparison.OrdinalIgnoreCase) => "Avvio...",
    _ when string.Equals(comando, "stop", StringComparison.OrdinalIgnoreCase) => "Arresto...",
    _ => "Comando non riconosciuto"
};

// Approccio 2: Normalizzazione con ToUpperInvariant (accettabile per switch)
var risultato2 = comando.ToUpperInvariant() switch
{
    "START" => "Avvio...",
    "STOP" => "Arresto...",
    _ => "Comando non riconosciuto"
};

Esempio completo: parser di configurazione

public sealed class ConfigParser
{
    private readonly FrozenDictionary<string, string> _impostazioni;

    public ConfigParser(IEnumerable<KeyValuePair<string, string>> rawSettings)
    {
        // FrozenDictionary è ottimizzato per letture frequenti (immutabile dopo la creazione)
        _impostazioni = rawSettings.ToFrozenDictionary(
            kvp => kvp.Key,
            kvp => kvp.Value,
            StringComparer.OrdinalIgnoreCase);
    }

    public string? Get(string chiave) =>
        _impostazioni.TryGetValue(chiave, out var valore) ? valore : null;
}

// Utilizzo
var config = new ConfigParser(new[]
{
    new KeyValuePair<string, string>("DatabaseUrl", "Server=..."),
    new KeyValuePair<string, string>("MaxConnections", "100"),
});

Console.WriteLine(config.Get("databaseurl"));    // "Server=..."
Console.WriteLine(config.Get("MAXCONNECTIONS")); // "100"

Riepilogo: regole pratiche

1. Usa OrdinalIgnoreCase per chiavi, identificatori, URL, nomi di file, comandi, header HTTP.
2. Usa CurrentCulture solo per testo mostrato all’utente, quando le regole locali sono rilevanti.
3. Non usare ToLower() per confronti: alloca inutilmente e dipende dalla cultura.
4. Specifica sempre StringComparison esplicitamente nelle chiamate a Equals e Compare.
5. Usa StringComparer quando passi logica di confronto a strutture dati.
6. Usa MemoryExtensions su Span<char> per hot path ad alta frequenza e senza allocazioni.

Seguendo queste linee guida, si eliminano intere classi di bug difficili da riprodurre e si ottiene codice più robusto, portabile e performante.

Fonte: DevLeader — C# String Comparison: Equals, OrdinalIgnoreCase, StringComparer, and Culture Pitfalls

C# String Comparison: Equals, OrdinalIgnoreCase, StringComparer, and Culture Pitfalls

Master C# string comparison with Equals, OrdinalIgnoreCase, StringComparer, and culture-sensitive APIs. Avoid the ToLower() antipattern and Turkish i problem.

^{Nick Cosentino (Dev Leader)}

(in)sicurezza digitale

2026-04-16 15:08:07

Qilin e Warlock BYOVD: come il ransomware disabilita 300+ soluzioni EDR utilizzando driver vulnerabili

Qilin e Warlock, due dei ransomware RaaS (Ransomware-as-a-Service) più sofisticati del panorama criminale, hanno potenziato significativamente le loro capacità di evasione implementando la tecnica BYOVD (Bring Your Own Vulnerable Driver). La nuova strategia consente ai malware di disabilitare oltre 300 soluzioni EDR/XDR utilizzando driver vulnerabili del kernel, rendendo inefficaci quasi tutti i sistemi di rilevamento degli endpoint contemporanei.

Dalla lateralizzazione alla disattivazione: la nuova tattica Qilin

Qilin rappresenta una delle principali operazioni di ransomware RaaS attualmente operative. Il gruppo ha consolidato il controllo su decine di reti aziendali utilizzando metodologie di accesso ben collaudate e movimentazione laterale. Tuttavia, la fase finale dell’attacco era frequentemente rilevata dagli EDR in grado di identificare comportamenti malware tipici durante la crittografia di file.

Con l’introduzione della catena di infezione EDR-Killer, Qilin ha chiuso questa lacuna critica. Gli attacchi moderni seguono un pattern ben definito: accesso iniziale, lateralizzazione (6 giorni medi), disattivazione degli EDR, dispiegamento ransomware.

La catena multi-stadio: msimg32.dll e il carico del Kernel

La catena di infezione EDR-Killer di Qilin utilizza la tecnica classica del DLL Side-Loading per eseguire una DLL malevola denominata “msimg32.dll”. Per mantenere la funzionalità attesa, la DLL malevola invia gli API call legittimi alla libreria legittima in C:\Windows\System32, mascherando completamente la sua attività malevola.

Lo stadio 1 implementa una tabella slot-policy per l’evasione delle syscall e la tecnica “Halo’s Gate”, consentendo al codice malware di invocare direttamente funzioni di kernel bypassando i filtri tradizionali. Gli stadi 2-3 presentano offuscamento del flusso di controllo VEH-based complesso.

Il doppio carico di driver: rwdrv.sys e hlpdrv.sys

rwdrv.sys è una versione rinominata di “ThrottleStop.sys”, uno strumento legittimo di tuning dei processori Intel. Sfruttando una vulnerabilità nel driver originale, Qilin lo utilizza per ottenere accesso diretto alla memoria fisica del sistema. Una volta caricato nel kernel, rwdrv.sys funziona come un livello di accesso hardware di modo kernel.

hlpdrv.sys è il vero “EDR killer”. Lavora in stretto coordinamento con rwdrv.sys per terminare i processi associati a oltre 300 diversi driver EDR appartenenti a praticamente ogni maggiore fornitore di sicurezza. Prima di caricare hlpdrv.sys, il componente EDR-killer annulla la registrazione dei callback di monitoraggio stabiliti dall’EDR, accecando efficacemente lo strumento di rilevamento a livello di kernel.

Meccanismo di disattivazione tecnica: callback unregistration

I sistemi di rilevamento moderni utilizzano callback di kernel registrati per monitorare eventi critici: creazione di processi, creazione di thread, caricamento di moduli/DLL, operazioni di file system. Iterando attraverso una lista hardcoded di oltre 300 driver EDR, Qilin annulla sistematicamente la registrazione dei loro callback di monitoraggio.

Senza questi callback, l’EDR diventa essenzialmente cieco: non può rilevare nuovi processi, non può intercettare thread sospetti, non può monitorare il caricamento di moduli malware. Una volta che i callback sono stati annullati, hlpdrv.sys procede a terminare i processi del servizio EDR stesso, disattivando completamente la protezione in tempo reale.

Timeline e implicazioni per la difesa

L’analisi forense rivela un pattern tattico coerente: accesso iniziale via credenziali compromesse, lateralizzazione (6 giorni medi), EDR disattivazione, dispiegamento ransomware. Questa evoluzione tattica rappresenta una significativa escalation nella sofisticazione dei ransomware RaaS.

Per la difesa: implementare il Kernel Patch Protection (KPP/HVCI), implementare Device Guard per il whitelisting dei driver firmati, implementare segmentazione di rete aggressiva, monitorare il movimento laterale, implementare il privileged access management (PAM). Se il caricamento di un driver sospetto viene rilevato, avviare immediatamente un killchain completo dell’incidente con isolamento di rete e acquisizione forense.

(in)sicurezza digitale

2026-04-16 09:27:30

APT28 PRISMEX: la suite malware di spionaggio dell’esercito russo colpisce l’Ucraina e gli alleati NATO

Si parla di:
Toggle

• La campagna PRISMEX: steganografia e doppi intenti
• Anatomia della suite PRISMEX
• Sfruttamento Zero-Day e tattica di preparazione dell’infrastruttura
• Catena di accesso iniziale e vettori di infezione
• Indicatori tecnici e meccanismi di persistenza
• Implicazioni strategiche e di difesa

L’APT28 (noto anche come Pawn Storm, Forest Blizzard, Fancy Bear) lancia una sofisticata campagna di spear-phishing che distribuisce la suite malware PRISMEX, combinando steganografia avanzata, spoofing COM e abuso di servizi cloud legittimi. La campagna prende di mira infrastrutture critiche ucraine e partner logistici NATO in Polonia, Romania, Slovenia, Turchia, Slovacchia e Repubblica Ceca, segnalando un’escalation significativa delle operazioni di cyber-spionaggio russo.

La campagna PRISMEX: steganografia e doppi intenti

A partire da almeno settembre 2025, l’APT28 ha dispiegato la suite PRISMEX in una campagna mirata a enti governativi ucraini (corpi esecutivi centrali, servizi di idrometeorologia, difesa, gestione delle emergenze) e partner logistici militari in tutta Europa orientale e i Balcani. La campagna è particolarmente preoccupante per due motivi: la rapidità di sfruttamento di vulnerabilità zero-day e la sofisticazione dell’infrastruttura di comando e controllo.

PRISMEX combina quattro componenti malware distinti, ognuno con funzioni specifiche nella catena infettiva. Lo spionaggio e le capacità distruttive coesistono nello stesso malware, suggerendo una doppia intenzione: raccogliere intelligence militare-strategica e preparare potenziali operazioni di sabotaggio dirompente contro infrastrutture critiche alleate.

Anatomia della suite PRISMEX

PrismexSheet è il componente iniziale: un documento Excel malevolo con macro VBA che estrae payload nascosti nel file tramite steganografia. Dopo che la macro è abilitata, il componente stabilisce persistenza tramite hijacking COM e visualizza un documento esca relativo a inventari di droni e prezzi di equipaggiamento militare per ingannare l’utente.

PrismexDrop è un dropper nativo che prepara l’ambiente per lo sfruttamento successivo, utilizza task pianificati e hijacking COM DLL per mantenere la persistenza nel sistema compromesso.

PrismexLoader è la componente più sofisticata dal punto di vista tecnico. Funziona come un proxy DLL che estrae il payload .NET successivo disperso nella struttura di un file PNG (“SplashScreen.png”) utilizzando un algoritmo personalizzato denominato “Bit Plane Round Robin”. Questo metodo di steganografia distribuisce i dati attraverso il file per eludere la rilevazione, consentendo l’esecuzione completamente in memoria con tracce minime su disco.

PrismexStager è un impianto COVENANT Grunt che abusa del servizio cloud Filen.io per le comunicazioni di comando e controllo. Questa infrastruttura consente al traffico malevolo di mimetizzarsi con le comunicazioni web normali crittografate, bypassando i filtri basati sulla reputazione e le regole firewall.

Sfruttamento Zero-Day e tattica di preparazione dell’infrastruttura

L’APT28 ha dimostrato una capacità straordinaria di sfruttare le vulnerabilità quasi immediatamente dopo la divulgazione pubblica. Le vulnerabilità CVE-2026-21509 (sfruttamento RTF) e CVE-2026-21513 (bypass della protezione del browser) sono state integrate nella campagna PRISMEX con velocità allarmante.

Ancora più preoccupante: l’infrastruttura preparatoria è stata osservata il 12 gennaio 2026, esattamente due settimane prima della divulgazione pubblica di CVE-2026-21509. Questo suggerisce fortemente che l’APT28 possedeva una conoscenza zero-day della vulnerabilità, anticipando di settimane la divulgazione ufficiale da parte di Microsoft.

Catena di accesso iniziale e vettori di infezione

Gli attacchi iniziano con email di spear-phishing particolarmente sofisticate che sfruttano contesti geopolitici attuali. I temi utilizzati includono briefing su addestramento militare, avvisi meteorologici critici, documenti su contrabbando di armi e logistica militare, e inventari di equipaggiamento difensivo.

CVE-2026-21509 (una vulnerabilità di esecuzione di codice remoto in file RTF) forza una connessione ai server WebDAV controllati dagli attaccanti, consentendo il download e l’esecuzione di PrismexSheet. CVE-2026-21513 consente l’esecuzione silenziosa di codice bypassando le protezioni del browser.

Indicatori tecnici e meccanismi di persistenza

I meccanismi di persistenza includono COM hijacking, task pianificati che riavviano explorer.exe a intervalli regolari, esecuzione senza file tramite caricamento runtime .NET, e abuso del servizio cloud Filen.io per C2. La steganografia “Bit Plane Round Robin” di PrismexLoader è particolarmente insidiosa, distribuendo il payload nei piani di bit di un file PNG per consentire ai difensori di vedere un’immagine visivamente normale mentre nasconde efficacemente la logica malware.

Implicazioni strategiche e di difesa

Per le organizzazioni nel settore della difesa, della logistica e delle infrastrutture critiche in Europa orientale e nei Balcani: monitorare le connessioni a Filen.io da endpoint aziendali, cercare file PNG in posizioni inusuali, analizzare le macros di Excel per riferimenti a URL di download, implementare il whitelisting delle applicazioni, disabilitare i task scheduler non autorizzati, e applicare immediatamente le patch per CVE-2026-21509 e CVE-2026-21513.

APT28 PRISMEX: la suite malware di spionaggio dell'esercito russo colpisce l'Ucraina e gli alleati NATO - (in)sicurezza digitale

L'APT28 lancia una sofisticata campagna PRISMEX combinando steganografia avanzata e abuso di servizi cloud legittimi per colpire l'Ucraina e i partner NATO con capacità di spionaggio e sabotaggio.

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-16 07:47:38

.NET 11 Preview 3: tutte le novità del terzo rilascio anticipato

.NET 11 è ancora in fase di sviluppo, ma il terzo Preview rilasciato il 14 aprile 2026 porta con sé una serie di novità concrete e già sperimentabili. Dalle librerie di sistema al runtime JIT, dall’SDK alla toolchain, questo rilascio intermedio offre uno sguardo chiaro su dove sta andando l’ecosistema .NET. Vediamo nel dettaglio cosa c’è di nuovo e cosa vale la pena testare subito nei propri progetti.

Novità nel Runtime e JIT

Il team del runtime ha rimosso il requisito del flag di opt-in per le API async previewed nelle versioni precedenti: alcune funzionalità asincrone del runtime sono ora accessibili senza annotazioni speciali. Sul fronte delle prestazioni, il JIT compiler è stato ottimizzato in tre aree chiave:

• Switch statement: migliorata la generazione di codice macchina per costrutti switch complessi
• Bounds check: eliminati controlli ridondanti sugli array in scenari comuni
• Type cast: ridotta la latenza nelle operazioni di cast tra tipi gerarchicamente correlati

Sul fronte WebAssembly, .NET 11 introduce il formato WebCIL, un nuovo formato di packaging per i moduli .wasm, insieme a miglioramenti al debugging in ambiente browser. Chi sviluppa applicazioni Blazor WebAssembly beneficerà di esperienze di debug più fluide.

Librerie di Sistema: JSON, Compressione e Regex

System.Text.Json riceve controllo più granulare sulla naming strategy e sulla gestione dei valori di default. Sarà possibile configurare i serializzatori per ignorare specifiche proprietà con valori predefiniti in modo più preciso rispetto a quanto offriva il parametro DefaultIgnoreCondition.

La novità più interessante lato compressione è l’aggiunta di Zstandard (zstd) in System.IO.Compression. Zstandard è l’algoritmo di compressione sviluppato da Meta, noto per offrire un ottimo trade-off tra velocità e rapporto di compressione — spesso superiore a gzip e deflate. Esempio di utilizzo:

using System.IO.Compression;

// Compressione con Zstandard
using var input = File.OpenRead("dati.json");
using var output = File.Create("dati.json.zst");
using var compressor = new ZstandardStream(output, CompressionMode.Compress);
await input.CopyToAsync(compressor);

In aggiunta, la lettura di file ZIP ora valida i checksum CRC32 automaticamente, rendendo più robusta la gestione degli archivi corrotti o manomessi.

Per le espressioni regolari, il motore riconosce ora tutte le sequenze Unicode di newline, migliorando la portabilità del parsing testuale cross-platform.

SDK: Nuove Funzionalità da CLI

L’SDK riceve alcune aggiunte molto pratiche per chi lavora da terminale:

Passare variabili d’ambiente con dotnet run -e

# Passare una variabile d'ambiente al processo durante lo sviluppo
dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e ConnectionStrings__Default="Server=..."

Finalmente si può sovrascrivere variabili d’ambiente senza toccare launchSettings.json o esportare variabili nello shell corrente.

Top-level programs multi-file

I programmi con top-level statements (introdotti in C# 9) potranno ora distribuirsi su più file sorgente. Questo alleggerisce il vincolo di avere tutto in un unico Program.cs per i progetti di tipo file-based, come script o tool CLI leggeri.

dotnet watch migliorato

Lo strumento dotnet watch ha ricevuto tre miglioramenti rilevanti: supporto ai progetti .NET Aspire, crash recovery automatico e miglioramenti specifici per applicazioni Windows desktop (WPF/WinForms).

C# 14: Union Types in Anteprima

Preview 3 include un’anteprima degli union types in C# 14. Questa funzionalità, molto attesa, consente di dichiarare tipi che possono contenere uno tra un insieme definito di tipi, avvicinando C# a pattern già presenti in F#, TypeScript e Rust:

// Sintassi ipotetica - ancora in preview, soggetta a variazioni
union Result<T>
{
    T Value,
    Exception Error
}

var result = GetData();
var output = result switch
{
    Result<string>.Value(var v) => $"Successo: {v}",
    Result<string>.Error(var e) => $"Errore: {e.Message}"
};

Attenzione: la sintassi è ancora sperimentale e potrebbe cambiare nelle release successive.

ASP.NET Core in .NET 11 Preview 3

Tre aggiornamenti principali per il framework web:

Compressione Zstandard per le risposte HTTP

ASP.NET Core ora supporta la compressione zstd nelle risposte HTTP e la decompressione delle richieste in arrivo. Da configurare in Program.cs:

builder.Services.AddResponseCompression(options =>
{
    options.Providers.Add<ZstandardCompressionProvider>();
    options.EnableForHttps = true;
});

Blazor Virtualize con altezze variabili

Il componente <Virtualize> di Blazor ora si adatta a elementi di altezza variabile a runtime, risolvendo un limite storico che richiedeva di specificare un’altezza fissa per gli elementi della lista virtualizzata.

HTTP/3 più reattivo

L’avvio dell’elaborazione delle richieste HTTP/3 è anticipato, riducendo la latenza percepita nelle prime connessioni su protocollo QUIC.

Entity Framework Core: GetEntriesForState()

EF Core in .NET 11 introduce ChangeTracker.GetEntriesForState(), un metodo che consente di interrogare le entry per stato (Added, Modified, Deleted) senza scatenare un cycle di change detection — operazione potenzialmente costosa in grafi di oggetti complessi:

// Prima: scatenava change detection su tutto il grafo
var modified = context.ChangeTracker.Entries()
    .Where(e => e.State == EntityState.Modified)
    .ToList();

// Ora: accesso diretto per stato, senza overhead di detection
var modified = context.ChangeTracker
    .GetEntriesForState(EntityState.Modified)
    .ToList();

Container Images Firmati

Le immagini container ufficiali di .NET sono ora firmate digitalmente, permettendo la verifica della catena di custodia prima del deployment. Questo è un passo importante per le pipeline DevSecOps che richiedono provenance verificabile dei componenti software.

Come Provare .NET 11 Preview 3

# Scaricare il SDK da https://dotnet.microsoft.com/download/dotnet/11.0
dotnet --version
# Output atteso: 11.0.0-preview.3.xxxxx

# Creare un progetto di test
dotnet new console -n test-dotnet11 --framework net11.0

Conclusione

.NET 11 Preview 3 è un rilascio ricco, che tocca trasversalmente runtime, SDK, ASP.NET Core ed EF Core. Le novità più impattanti per la produzione futura sono il supporto a Zstandard, gli union types in C# 14 e le ottimizzazioni JIT. Si consiglia di testare le nuove funzionalità dell’SDK — in particolare dotnet run -e — già ora, poiché entreranno probabilmente stabili con il rilascio di novembre 2026.

Fonte: devblogs.microsoft.com — .NET 11 Preview 3 is now available!, 14 aprile 2026

.NET 11 Preview 3 is now available! - .NET Blog

Find out about the new features in .NET 11 Preview 3 across the .NET runtime, SDK, libraries, ASP.NET Core, .NET MAUI, C#, Entity Framework Core, container images, and more!

^{.NET Team (.NET Blog)}

informapirata

2023-03-27 11:39:57

Sei un utente Mastodon e vorresti usare i gruppi/forum Friendica e le comunità Lemmy? Allora questa guida fa per te!

informapirata.it/2023/03/27/ti…

Tips Mastodon: come usare i gruppi/forum Friendica e le comunità Lemmy - informapirata

^{informapirata}