.NET e .NET Framework per le app server

Articolo
05/10/2023

Sono disponibili due implementazioni .NET supportate per la compilazione di app lato server.

Implementazione	Versioni incluse
.NET	.NET Core 1.0 - 3.1, .NET 5 e versioni successive di .NET.
.NET Framework	.NET Framework 1.0 - 4.8

Entrambi condividono molti degli stessi componenti ed è possibile condividere il codice tra i due. Tuttavia, esistono differenze fondamentali tra i due e la scelta dipende da ciò che si vuole eseguire. Questo articolo fornisce materiale sussidiario per identificare i casi in cui è opportuno usare ciascuna delle due opzioni.

Usare .NET per l'applicazione server quando:

Si hanno esigenze multipiattaforma.
Si destinazionino i microservizi.
Si usano contenitori Docker.
Si hanno esigenze di elevate prestazioni e scalabilità.
È necessaria l'installazione side-by-side delle versioni di .NET in base all'applicazione.

Usare .NET Framework per l'applicazione server nei casi seguenti:

L'app usa attualmente .NET Framework (si consiglia di optare per l'estensione anziché per la migrazione).
L'app usa librerie di terze parti o pacchetti NuGet non disponibili per .NET.
L'app usa tecnologie .NET Framework non disponibili per .NET.
L'app usa una piattaforma che non supporta .NET.

Quando scegliere .NET

Le sezioni seguenti forniscono una spiegazione più dettagliata dei motivi indicati in precedenza per la scelta di .NET in .NET Framework.

Esigenze multipiattaforma

Se l'applicazione Web o di servizio deve essere eseguita su più piattaforme, ad esempio Windows, Linux e macOS, usare .NET.

.NET supporta i sistemi operativi indicati in precedenza come workstation di sviluppo. Visual Studio fornisce un ambiente di sviluppo integrato (IDE) per Windows e macOS. È anche possibile usare Visual Studio Code, che viene eseguito in macOS, Linux e Windows. Visual Studio Code supporta .NET, tra cui IntelliSense e debug. La maggior parte degli editor di terze parti, ad esempio Sublime, Emacs e VI, funziona con .NET. Questi editor di terze parti accedono alla funzionalità IntelliSense dell'editor tramite Omnisharp. È anche possibile evitare qualsiasi editor di codice e usare direttamente l'interfaccia della riga di comando di .NET, disponibile per tutte le piattaforme supportate.

Architettura di microservizi

Un'architettura di microservizi consente di usare una combinazione di tecnologie in un limite di servizi. Questa combinazione di tecnologie consente di adottare gradualmente .NET per nuovi microservizi che funzionano con altri microservizi o servizi. Ad esempio, è possibile combinare microservizi o servizi sviluppati con .NET Framework, Java, Ruby o altre tecnologie monolitiche.

Le piattaforme di infrastruttura disponibili sono numerose. Azure Service Fabric è appositamente concepita per sistemi di microservizi complessi e di grandi dimensioni. Servizio app di Azure è la soluzione ideale per i microservizi senza stato. Le alternative ai microservizi basati su Docker si adattano a qualsiasi approccio ai microservizi, come illustrato nella sezione Contenitori . Tutte queste piattaforme supportano .NET e le rendono ideali per l'hosting dei microservizi.

Per altre informazioni sull'architettura dei microservizi, vedere Microservizi .NET. Architettura per applicazioni .NET in contenitori.

Contenitori

I contenitori vengono comunemente usati con un'architettura di microservizi. ma possano essere impiegati anche per creare contenitori di servizi o app Web basati su qualsiasi modello architettonico. .NET Framework può essere usato nei contenitori Windows. Tuttavia, la modularità e la natura leggera di .NET lo rendono una scelta migliore per i contenitori. Quando si crea e si distribuisce un contenitore, le dimensioni dell'immagine sono molto più piccole con .NET rispetto a .NET Framework. Poiché è multipiattaforma, è possibile distribuire app server in contenitori Docker Linux.

I contenitori Docker possono essere ospitati nella propria infrastruttura Linux o Windows o in un servizio cloud, ad esempio servizio Azure Kubernetes. Il servizio Azure Kubernetes consente infatti di gestire, orchestrare e ridimensionare applicazioni basate su contenitore nel cloud.

Sistemi a prestazioni elevate e scalabili

Quando il sistema necessita delle migliori prestazioni e scalabilità possibili, .NET e ASP.NET Core sono le opzioni migliori. Il runtime del server ad alte prestazioni per Windows Server e Linux rende ASP.NET Core un framework Web con prestazioni ottimali nei benchmark TechEmpower.

Le prestazioni e la scalabilità sono particolarmente rilevanti per le architetture di microservizi, in cui potrebbero essere in esecuzione centinaia di microservizi. Con ASP.NET Core i sistemi vengono eseguiti con un numero di server/macchine virtuali sensibilmente inferiore I server/macchine virtuali ridotti consentono di risparmiare sui costi relativi all'infrastruttura e all'hosting.

Versioni side-by-side di .NET a livello di applicazione

Per installare applicazioni con dipendenze da versioni diverse di .NET, è consigliabile .NET. Questa implementazione supporta l'installazione side-by-side di versioni diverse del runtime .NET nello stesso computer. L'installazione side-by-side consente più servizi nello stesso server, ognuno con la propria versione di .NET. riducendo inoltre i rischi e risparmiando sui costi degli aggiornamenti di applicazioni e delle operazioni IT.

L'installazione side-by-side non è possibile con .NET Framework. Si tratta di un componente Windows e una sola versione può esistere in un computer alla volta. Ogni versione di .NET Framework sostituisce la versione precedente. Se si installa una nuova app destinata a una versione successiva di .NET Framework, è possibile interrompere le app esistenti eseguite nel computer perché la versione precedente è stata sostituita.

Quando scegliere .NET Framework

.NET offre vantaggi significativi per le nuove applicazioni e i modelli di applicazione. .NET Framework continua tuttavia a essere la scelta naturale per molti scenari esistenti e, di conseguenza, .NET Framework non viene sostituito da .NET per tutte le applicazioni server.

Applicazioni .NET Framework correnti

Nella maggior parte dei casi, non è necessario eseguire la migrazione delle applicazioni esistenti a .NET. È invece consigliabile usare .NET durante l'estensione di un'applicazione esistente, ad esempio la scrittura di un nuovo servizio Web in ASP.NET Core.

Librerie di terze parti o pacchetti NuGet non disponibili per .NET

.NET Standard consente la condivisione del codice tra tutte le implementazioni di .NET, tra cui .NET Core/5+. Con .NET Standard 2.0, una modalità di compatibilità consente ai progetti .NET Standard e .NET di fare riferimento alle librerie .NET Framework. Per altre informazioni, vedere Supporto per le librerie .NET Framework.

È necessario usare .NET Framework solo nei casi in cui le librerie o i pacchetti NuGet usano tecnologie non disponibili in .NET Standard o .NET.

Tecnologie .NET Framework non disponibili per .NET

Alcune tecnologie .NET Framework non sono disponibili in .NET. L'elenco seguente mostra le tecnologie più comuni non trovate in .NET:

Web Forms ASP.NET applicazioni: Web Forms ASP.NET sono disponibili solo in .NET Framework. non è possibile usare ASP.NET Core per Web Forms ASP.NET.
Pagine Web ASP.NET applicazioni: Pagine Web ASP.NET non sono incluse in ASP.NET Core.
Servizi correlati al flusso di lavoro: Windows Workflow Foundation (WF), Servizi flusso di lavoro (WCF + WF in un singolo servizio) e WCF Data Services (in precedenza noto come "ADO.NET Data Services") sono disponibili solo in .NET Framework.
Supporto del linguaggio: Visual Basic e F# sono attualmente supportati in .NET, ma non per tutti i tipi di progetto. Per un elenco dei modelli di progetto supportati, vedere le opzioni del modello per dotnet new.

Per altre informazioni, vedere Tecnologie .NET Framework non disponibili in .NET.

La piattaforma non supporta .NET

Alcune piattaforme Microsoft o di terze parti non supportano .NET. Alcuni servizi di Azure forniscono un SDK non ancora disponibile per l'utilizzo in .NET. In questi casi, è possibile usare l'API REST equivalente anziché l'SDK client.