Panoramica delle versioni del runtime per Funzioni di Azure
Funzioni di Azure supporta attualmente due versioni dell'host di runtime. La tabella seguente illustra in dettaglio le versioni di runtime attualmente supportate, il livello di supporto e quando devono essere usate:
Versione | Livello di supporto | Descrizione |
---|---|---|
4.x | Disponibilità generale | Versione di runtime consigliata per le funzioni in tutti i linguaggi. Vedere Versioni della lingua supportate. |
1.x | Disponibilità generale (il supporto termina il 14 settembre 2026) | Supportato solo per le app C# che devono usare .NET Framework. Questa versione è in modalità manutenzione, con miglioramenti forniti solo nelle versioni successive. Il supporto terminerà per la versione 1.x il 14 settembre 2026. È consigliabile eseguire la migrazione delle app alla versione 4.x, che supporta .NET Framework 4.8, .NET 6, .NET 8 e .NET 9. |
Importante
A partire dal 13 dicembre 2022, le app per le funzioni in esecuzione nelle versioni 2.x e 3.x del runtime di Funzioni di Azure hanno raggiunto la fine del supporto “Extended”. Per altre informazioni, vedere Versioni ritirata.
Questo articolo illustra in dettaglio alcune delle differenze tra le versioni supportate, come creare ogni versione e come modificare la versione in cui vengono eseguite le funzioni.
Livelli di supporto
Esistono due livelli di supporto:
- Disponibile a livello generale - Il linguaggio è completamente supportato e approvato per l'uso in produzione.
- Anteprima - Il linguaggio non è ancora supportato ma si prevede che in futuro diventi disponibile a livello generale.
Lingue
Tutte le funzioni in un'app per le funzioni devono condividere lo stesso linguaggio. Quando si crea l'app si sceglie il linguaggio delle funzioni nell'app per le funzioni. Il linguaggio dell'app per le funzioni viene mantenuto nell'impostazione FUNCTIONS_WORKER_RUNTIME e non può essere modificato quando sono presenti funzioni esistenti.
La tabella seguente illustra le versioni di .NET supportate da Funzioni di Azure. Selezionare il linguaggio di sviluppo preferito nella parte superiore dell'articolo.
La versione supportata di .NET dipende sia dalla versione del runtime di Funzioni che dal modello di esecuzione scelto:
Il codice della funzione viene eseguito in un processo di lavoro .NET separato. Usare con le versioni supportate di .NET e .NET Framework. Per altre informazioni, vedere Sviluppare funzioni di processo di lavoro isolato .NET.
Versione supportata | Livello di supporto | Data EOL della community prevista |
---|---|---|
.NET 9 | Anteprima | Vedere i criteri |
.NET 8 | Disponibilità generale | 10 novembre 2026 |
.NET 6 | Disponibilità generale | 12 novembre 2024 |
.NET Framework 4.8 | Disponibilità generale | Vedere i criteri |
.NET 7 è stato precedentemente supportato nel modello di lavoro isolato, ma ha raggiunto la fine del supporto ufficiale il 14 maggio 2024.
Per altre informazioni, vedere Guida per l'esecuzione di Funzioni di Azure C# in un processo di lavoro isolato.
La tabella seguente illustra le versioni del linguaggio supportate per le funzioni Java. Selezionare il linguaggio di sviluppo preferito nella parte superiore dell'articolo.
Versione supportata | Livello di supporto | Data EOL della community prevista |
---|---|---|
Java 21 (solo Linux) | Anteprima | 2028 settembre 2021 |
Java 17 | Disponibilità generale | Settembre 2027 |
Java 11 | Disponibilità generale | Settembre 2027 |
Java 8 | Disponibilità generale | 30 novembre 2026 |
Per altre informazioni, vedere la guida per sviluppatori Java per funzioni di Azure.
La tabella seguente illustra le versioni del linguaggio supportate per le funzioni di Node.js. Selezionare il linguaggio di sviluppo preferito nella parte superiore dell'articolo.
Versione supportata | Livello di supporto | Data EOL della community prevista |
---|---|---|
Node.js 22 | Anteprima | 30 aprile 2027 |
Node.js 20 | Disponibilità generale | 30 aprile 2026 |
Node.js 18 | Disponibilità generale | 30 aprile 2025 |
TypeScript è supportato tramite compilazione da sorgente a sorgente di JavaScript. Per altre informazioni, vedere la guida per sviluppatori di Funzioni di Azure Node.js.
La tabella seguente illustra la versione del linguaggio supportata per le funzioni di PowerShell. Selezionare il linguaggio di sviluppo preferito nella parte superiore dell'articolo.
Versione supportata | Livello di supporto | Data EOL della community prevista |
---|---|---|
PowerShell 7.4 | Disponibilità generale | 10 novembre 2026 |
PowerShell 7.2 | Disponibilità generale | venerdì 8 novembre 2024 |
Per altre informazioni, vedere Guida per sviluppatori di PowerShell per Funzioni di Azure.
La tabella seguente illustra le versioni del linguaggio supportate per le funzioni Python. Selezionare il linguaggio di sviluppo preferito nella parte superiore dell'articolo.
Versione supportata | Livello di supporto | Data EOL della community prevista |
---|---|---|
Python 3.11 | Disponibilità generale | Ottobre 2021 |
Python 3.10 | Disponibilità generale | Ottobre 2026 |
Python 3.9 | Disponibilità generale | Ottobre 2025 |
Python 3.8 | Disponibilità generale | Ottobre 2024 |
Per altre informazioni, vedere Guida per sviluppatori Python per Funzioni di Azure.
Per informazioni sulle modifiche previste per il supporto dei linguaggi di programmazione, vedere Roadmap per Azure.
Per informazioni sulle versioni del linguaggio delle versioni supportate in precedenza del runtime di Funzioni, vedere Versioni di runtime ritirata.
Esecuzione in una versione specifica
La versione del runtime di Funzioni usata dalle app pubblicate in Azure è determinata dall'impostazione dell'applicazione FUNCTIONS_EXTENSION_VERSION
. In alcuni casi e per determinate lingue, è possibile applicare altre impostazioni.
Per impostazione predefinita, le app per le funzioni create nel portale di Azure, dall'interfaccia della riga di comando di Azure o dagli strumenti di Visual Studio sono impostate sulla versione 4.x. Se necessario, è possibile modificare questa versione. È possibile effettuare il downgrade della versione di runtime alla versione 1.x solo dopo aver creato l'app per le funzioni, ma prima di aggiungere qualsiasi funzione. L'aggiornamento a una versione principale successiva è consentito anche con le app con funzioni esistenti.
Migrazione di app per le funzioni esistenti
Quando l'app ha funzioni esistenti, è necessario adottare precauzioni prima di passare a una versione di runtime principale successiva. Gli articoli seguenti illustrano in dettaglio le modifiche di rilievo tra le versioni principali, incluse le modifiche di rilievo specifiche della lingua. Forniscono anche istruzioni dettagliate per una corretta migrazione dell'app per le funzioni esistente.
- Eseguire la migrazione dalla versione di runtime 3.x alla versione 4.x
- Eseguire la migrazione dalla versione di runtime 1.x alla versione 4.x
Modifica della versione delle app in Azure
Vengono usati i valori di versione di runtime principali seguenti:
Valore | Destinazione del runtime |
---|---|
~4 |
4.x |
~1 |
1.x |
Importante
Non modificare arbitrariamente questa impostazione dell'app, perché potrebbero essere necessarie altre modifiche alle impostazioni dell'app e alle modifiche apportate al codice della funzione. Per le app per le funzioni esistenti, seguire le istruzioni di migrazione.
Aggiunta a una versione secondaria specifica
Per risolvere i problemi che l'app per le funzioni potrebbe avere quando è in esecuzione nella versione principale più recente, è necessario aggiungere temporaneamente l'app a una versione secondaria specifica. L'aggiunta offre il tempo necessario per eseguire correttamente l'app nella versione principale più recente. Il modo in cui si aggiunge a una versione secondaria differisce tra Windows e Linux. Per altre informazioni, vedere Come specificare le versioni del run-time per Funzioni di Azure.
Le versioni secondarie meno recenti vengono rimosse periodicamente da Funzioni. Per le ultime notizie sulle versioni di Funzioni di Azure, inclusa la rimozione di versioni secondarie meno recenti specifiche, monitorare gli annunci del servizio app di Azure.
Versioni minime delle estensioni
Tecnicamente non esiste una correlazione tra le versioni dell'estensione di binding e la versione del runtime di Funzioni. Tuttavia, a partire dalla versione 4.x il runtime di Funzioni applica una versione minima per tutte le estensioni di trigger e binding.
Se viene visualizzato un avviso relativo a un pacchetto che non soddisfa una versione minima richiesta, è consigliabile aggiornare il pacchetto NuGet alla versione minima come si farebbe normalmente. I requisiti minimi di versione per le estensioni usate in Funzioni v4.x sono disponibili nel file di configurazione collegato.
Per lo script C#, aggiornare il riferimento al bundle di estensione nel host.json come indicato di seguito:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.0.0, 5.0.0)"
}
}
Tecnicamente non esiste una correlazione tra le versioni del bundle di estensione e la versione del runtime di Funzioni. Tuttavia, a partire dalla versione 4.x il runtime di Funzioni applica una versione minima per i bundle di estensioni.
Se viene visualizzato un avviso relativo alla versione del bundle di estensione che non soddisfa una versione minima richiesta, aggiornare il riferimento al bundle di estensione esistente nel host.json come indicato di seguito:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.0.0, 5.0.0)"
}
}
Per altre informazioni sui bundle di estensioni, vedere Bundle di estensioni.
Versioni ritirate
Importante
Il supporto terminerà per la versione 1.x del runtime di Funzioni di Azure il 14 settembre 2026. È consigliabile eseguire la migrazione delle app alla versione 4.x per il supporto completo.
Queste versioni del runtime di Funzioni hanno raggiunto la fine del supporto esteso il 13 dicembre 2022.
Versione | Livello di supporto corrente | Livello di supporto precedente |
---|---|---|
3.x | Non più supportato | Disponibilità generale |
2.x | Non più supportato | Disponibilità generale |
Appena possibile, è consigliabile eseguire la migrazione delle app alla versione 4.x per ottenere il supporto completo. Per un set completo di istruzioni di migrazione specifiche del linguaggio, vedere Eseguire la migrazione delle app a Funzioni di Azure versione 4.x.
Le app che usano le versioni 2.x e 3.x possono comunque essere create e distribuite dalla pipeline DevOps CI/CD e tutte le app esistenti continuano a essere eseguite senza modifiche di rilievo. Tuttavia, le app non sono idonee per nuove funzionalità, patch di sicurezza e ottimizzazioni delle prestazioni. È possibile ottenere il supporto del servizio correlato solo dopo l'aggiornamento delle app alla versione 4.x.
La fine del supporto per le versioni 2.x e 3.x è dovuta alla fine del supporto per .NET Core 3.1, che aveva come dipendenza principale. Questo requisito influisce su tutti i linguaggi supportati da Funzioni di Azure.
Versioni dell'applicazione sviluppate in locale
È possibile apportare gli aggiornamenti seguenti alle app per le funzioni per modificare in locale le versioni di destinazione.
Versioni del runtime di Visual Studio
In Visual Studio è possibile selezionare la versione del runtime quando si crea un progetto. Gli strumenti di Funzioni di Azure per Visual Studio supportano le due versioni di runtime principali. Durante il debugging e la pubblicazione viene usata la versione corretta in base alle impostazioni del progetto. Le impostazioni della versione vengono definite nel file .csproj
nelle proprietà seguenti:
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
Se si usa il modello di lavoro isolato, è possibile scegliere net8.0
, net6.0
o net48
come framework di destinazione. È anche possibile scegliere di usare il supporto dell'anteprima per net9.0
. Se si usa il modello In-Process, è possibile scegliere net8.0
o net6.0
ed è necessario includere l'estensione Microsoft.NET.Sdk.Functions
impostata su almeno 4.4.0
.
.NET 7 è stato precedentemente supportato nel modello di lavoro isolato, ma ha raggiunto la fine del supporto ufficiale il 14 maggio 2024.
Visual Studio Code e Azure Functions Core Tools
Azure Functions Core Tools viene usato per lo sviluppo da riga di comando e anche dall'estensione di Funzioni di Azure per Visual Studio Code. Per altre informazioni, vedere Installare gli strumenti di base per Funzioni di Azure.
Per lo sviluppo con Visual Studio Code potrebbe anche essere necessario aggiornare l'impostazione utente per azureFunctions.projectRuntime
in base alla versione degli strumenti installata. Questa impostazione aggiorna anche i modelli e i linguaggi usati durante la creazione di un'app per le funzioni.
Bindings
A partire dalla versione 2.x, il runtime usa un nuovo modello di estendibilità binding che offre questi vantaggi:
Supporto per le estensioni di associazione di terze parti.
Separazione di runtime e associazioni. Questa modifica consente di applicare il controllo delle versioni alle estensioni di binding e di rilasciarle in modo indipendente. È ad esempio possibile scegliere di eseguire l'aggiornamento a una versione di un'estensione basata su una nuova versione di un SDK sottostante.
Ambiente di esecuzione più leggero, in cui solo le associazioni in uso sono note e vengono caricate dal runtime.
Ad eccezione dei trigger HTTP e Timer, tutti i binding devono essere esplicitamente aggiunti al progetto dell'app per le funzioni o registrati nel portale. Per altre informazioni, vedere Registrare le estensioni delle associazioni.
Nella tabella seguente sono indicati i binding supportati in ogni versione del runtime.
Questa tabella mostra le associazioni supportate nelle versioni principali del runtime di Funzioni di Azure:
Type | 1.x1 | 2.x e versioni successive2 | Trigger | Input | Output |
---|---|---|---|---|---|
Archiviazione BLOB | ✔ | ✔ | ✔ | ✔ | ✔ |
Azure Cosmos DB | ✔ | ✔ | ✔ | ✔ | ✔ |
Esplora dati di Azure | ✔ | ✔ | ✔ | ||
Azure SQL | ✔ | ✔ | ✔ | ✔ | |
Dapr4 | ✔ | ✔ | ✔ | ✔ | |
Griglia di eventi | ✔ | ✔ | ✔ | ✔ | |
Hub eventi | ✔ | ✔ | ✔ | ✔ | |
HTTP e webhook | ✔ | ✔ | ✔ | ✔ | |
Hub IoT | ✔ | ✔ | ✔ | ||
Kafka3 | ✔ | ✔ | ✔ | ||
App per dispositivi mobili | ✔ | ✔ | ✔ | ||
Hub di notifica di Azure | ✔ | ✔ | |||
Archiviazione code | ✔ | ✔ | ✔ | ✔ | |
Redis | ✔ | ✔ | |||
RabbitMQ3 | ✔ | ✔ | ✔ | ||
SendGrid | ✔ | ✔ | ✔ | ||
Bus di servizio | ✔ | ✔ | ✔ | ✔ | |
SignalR | ✔ | ✔ | ✔ | ✔ | |
Archiviazione tabelle | ✔ | ✔ | ✔ | ✔ | |
Timer | ✔ | ✔ | ✔ | ||
Twilio | ✔ | ✔ | ✔ |
Note:
- Il supporto terminerà per la versione 1.x del runtime di Funzioni di Azure il 14 settembre 2026. È consigliabile eseguire la migrazione delle app alla versione 4.x per il supporto completo.
- A partire dal runtime della versione 2.x, devono essere registrate tutte le associazioni tranne HTTP e Timer. Vedere Registrare le estensioni delle associazioni.
- I trigger non sono supportati nel piano A consumo. Richiede trigger basati sul runtime.
- Supportati solo in Kubernetes, IoT Edge e altre modalità self-hosted.
Durata del timeout di un'app per le funzioni
La durata del timeout per le funzioni in un'app per le funzioni è definita dalla proprietà functionTimeout
nel file di progetto host.json. Questa proprietà si applica in modo specifico alle esecuzioni di funzioni. Dopo l'avvio dell'esecuzione della funzione, la funzione deve restituire/rispondere entro la durata del timeout. Per evitare timeout, è importante scrivere funzioni solide. Per altre informazioni, vedere Migliorare le prestazioni e l'affidabilità di Funzioni di Azure.
La tabella seguente mostra i valori predefiniti e massimi (in minuti) per piani specifici:
Piano | Default | Massimo1 |
---|---|---|
Piano a consumo | 5 | 10 |
Piano a consumo flex | 30 | Unbounded2 |
Piano Premium | 304 | Unbounded2 |
Piano dedicato | 304 | Unbounded3 |
App contenitore | 30 | Unbounded4 |
- Indipendentemente dall'impostazione di timeout dell'app per le funzioni, 230 secondi è la quantità di tempo massima che una funzione attivata da HTTP può impiegare per rispondere a una richiesta. Il motivo è legato al timeout di inattività predefinito di Azure Load Balancer. Per tempi di elaborazione più lunghi, provare a usare lo schema asincrono di Durable Functions oppure rinviare il processo effettivo e restituire una risposta immediata.
- Non è prevista l'applicazione di una durata di esecuzione del timeout massima. Tuttavia, il periodo di tolleranza previsto per l'esecuzione di una funzione è di 60 minuti durante la riduzione per i piani a consumo Flex e Premium e un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
- Richiede l'impostazione del piano di servizio app su Always On. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
- Il timeout predefinito per la versione 1.x del runtime di Funzioni è senza limiti.
- Quando il numero minimo di repliche è impostato su zero, il timeout predefinito dipende dai trigger specifici usati nell'app.
Passaggi successivi
Per ulteriori informazioni, vedi le seguenti risorse: