Sviluppare Funzioni di Azure in locale con Core Tools

  • Articolo

Funzioni di Azure Core Tools consente di sviluppare e testare le funzioni nel computer locale. Quando si è pronti, è anche possibile usare Core Tools per distribuire il progetto di codice in Azure e usare le impostazioni dell'applicazione.

Si sta visualizzando la versione C# di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione Java di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione JavaScript di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione di PowerShell di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione python di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione TypeScript di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Installare gli strumenti di base per Funzioni di Azure

Il modo consigliato per installare Core Tools dipende dal sistema operativo del computer di sviluppo locale.

La procedura seguente usa un programma di installazione di Windows per installare Core Tools v4.x. Per altre informazioni su altri programmi di installazione basati su pacchetti, vedere il file leggimi Core Tools.

Scaricare ed eseguire il programma di installazione di Core Tools, in base alla versione di Windows:

Se in precedenza hai usato Windows Installer (MSI) per installare Core Tools in Windows, devi disinstallare la versione precedente da Installazione applicazioni prima di installare la versione più recente.

Per informazioni sui problemi relativi alla versione, vedere Versioni degli strumenti di base.

Creare il progetto locale

Importante

Per Python, è necessario eseguire i comandi Core Tools in un ambiente virtuale. Per altre informazioni, vedere Avvio rapido: Creare una funzione Python in Azure dalla riga di comando.

Nella finestra del terminale o da un prompt dei comandi eseguire il comando seguente per creare un progetto nella MyProjFolder cartella :

func init MyProjFolder --worker-runtime dotnet-isolated

Per impostazione predefinita, questo comando crea un progetto che viene eseguito in-process con l'host funzioni nella versione LTS (Long-Term Support) corrente di .NET Core. È possibile usare l'opzione --target-framework per specificare una versione supportata specifica di .NET, incluso .NET Framework. Vedere le informazioni di riferimento per func init.

Per un confronto tra i due modelli di processo .NET, vedere l'articolo confronto tra modalità processo.

Java usa un archetipo Maven per creare il progetto locale, insieme alla prima funzione attivata tramite HTTP. Invece di usare func init e func new, è consigliabile seguire la procedura descritta nella guida introduttiva alla riga di comando.

func init MyProjFolder --worker-runtime javascript --model V4

Questo comando crea un progetto JavaScript che usa la versione desiderata del modello di programmazione.

func init MyProjFolder --worker-runtime typescript --model V4

Questo comando crea un progetto TypeScript che usa la versione desiderata del modello di programmazione.

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

Questo comando crea un progetto Python che usa la versione desiderata del modello di programmazione.

Quando si esegue func init senza l'opzione --worker-runtime , viene richiesto di scegliere il linguaggio del progetto. Per altre informazioni sulle opzioni disponibili per il func init comando, vedere il func init riferimento.

Creare una funzione

Per aggiungere una funzione al progetto, eseguire il func new comando usando l'opzione --template per selezionare il modello di trigger. L'esempio seguente crea un trigger HTTP denominato MyHttpTrigger:

func new --template "Http Trigger" --name MyHttpTrigger

In questo esempio viene creato un trigger di Archiviazione coda denominato MyQueueTrigger:

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

Quando si aggiungono funzioni, si applicano le considerazioni seguenti:

  • Quando si esegue func new senza l'opzione --template , viene richiesto di scegliere un modello.

  • Usare il func templates list comando per visualizzare l'elenco completo dei modelli disponibili per la lingua.

  • Quando si aggiunge un trigger che si connette a un servizio, è necessario aggiungere anche un'impostazione dell'applicazione che fa riferimento a un stringa di connessione o a un'identità gestita al file local.settings.json. L'uso delle impostazioni dell'app in questo modo impedisce di dover incorporare le credenziali nel codice. Per altre informazioni, vedere Usare le impostazioni dell'app in locale.

  • Core Tools aggiunge anche un riferimento all'estensione di associazione specifica al progetto C#.

Per altre informazioni sulle opzioni disponibili per il func new comando, vedere il func new riferimento.

Aggiungere un'associazione alla funzione

Funzioni fornisce un set di associazioni di input e output specifiche del servizio, che semplificano la connessione della funzione ad altri servizi di Azure senza dover usare gli SDK client specifici del servizio. Per altre informazioni, vedere Concetti relativi a trigger e associazioni in Funzioni di Azure.

Per aggiungere un'associazione di input o output a una funzione esistente, è necessario aggiornare manualmente la definizione della funzione.

L'esempio seguente illustra la definizione della funzione dopo l'aggiunta di un'associazione di output queue Archiviazione a una funzione attivata tramite HTTP:

Poiché una funzione attivata da HTTP restituisce anche una risposta HTTP, la funzione restituisce un MultiResponse oggetto , che rappresenta sia l'output HTTP che quello della coda.

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

Questo esempio è la definizione dell'oggetto che include l'associazione MultiResponse di output:

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

Quando si applica tale esempio al proprio progetto, potrebbe essere necessario passare a e a HttpResponseData, a seconda che si usi o meno l'integrazione di ASP.NET IActionResult Core.HttpRequestDataHttpRequest

I messaggi vengono inviati alla coda al termine della funzione. Il modo in cui si definisce l'associazione di output dipende dal modello di processo. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Associazione di esempio per Node.js modello v4 non ancora disponibile.

Il modo in cui si definisce l'associazione di output dipende dalla versione del modello di Node.js. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

Il modo in cui si definisce l'associazione di output dipende dalla versione del modello Python. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Associazione di esempio per Node.js modello v4 non ancora disponibile.

Il modo in cui si definisce l'associazione di output dipende dalla versione del modello di Node.js. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Quando si aggiungono associazioni a una funzione, si applicano le considerazioni seguenti:

  • Quando si aggiungono associazioni che si connettono a un servizio, è necessario aggiungere anche un'impostazione dell'applicazione che fa riferimento a un'identità stringa di connessione o gestita al file local.settings.json. Per altre informazioni, vedere Usare le impostazioni dell'app in locale.
  • Quando si aggiunge un'associazione supportata, l'estensione deve essere già installata quando l'app usa il bundle di estensione. Per altre informazioni, vedere Bundle di estensioni.
  • Quando si aggiunge un'associazione che richiede una nuova estensione di associazione, è necessario aggiungere anche un riferimento a tale estensione di associazione specifica nel progetto C#.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Avviare il runtime di Funzioni

Prima di poter eseguire o eseguire il debug delle funzioni nel progetto, è necessario avviare l'host funzioni dalla directory radice del progetto. L'host abilita i trigger per tutte le funzioni nel progetto. Usare questo comando per avviare il runtime locale:

mvn clean package 
mvn azure-functions:run

func start

npm install
npm start

Questo comando deve essere eseguito in un ambiente virtuale.

All'avvio dell'host funzioni, restituisce un elenco di funzioni nel progetto, inclusi gli URL di qualsiasi funzione attivata da HTTP, come nell'esempio seguente:

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

Quando si eseguono le funzioni in locale, tenere presenti le considerazioni seguenti:

  • Per impostazione predefinita, l'autorizzazione non viene applicata localmente per gli endpoint HTTP. Questo significa che tutte le richieste HTTP locali vengono gestite come authLevel = "anonymous". Per altre informazioni, vedere l'articolo sul binding HTTP. È possibile usare l'opzione per richiedere l'autorizzazione durante l'esecuzione --enableAuth in locale. Per altre informazioni, vedere func start.

  • È possibile usare l'emulatore Local Azurite quando si eseguono funzioni che richiedono l'accesso a servizi di Archiviazione di Azure (coda Archiviazione, Archiviazione BLOB e Archiviazione tabelle) senza dover connettersi a questi servizi in Azure. Quando si usa l'emulazione locale, assicurarsi di avviare Azurite prima di avviare l'host locale (func.exe). Per altre informazioni, vedere Emulazione dell'archiviazione locale.

  • È possibile usare l'emulazione locale di Azurite per soddisfare i requisiti di archiviazione del ruolo di lavoro Python v2.

  • È possibile attivare funzioni non HTTP in locale senza connettersi a un servizio attivo. Per altre informazioni, vedere Eseguire una funzione locale.

  • Quando si includono le informazioni di connessione di Application Insights nel file local.settings.json, i dati di log locali sono scritti nell'istanza specifica di Application Insights. Per mantenere i dati di telemetria locali separati dai dati di produzione, è consigliabile usare un'istanza separata di Application Insights per lo sviluppo e il test.

  • Quando si usa la versione 1.x di Core Tools, usare invece il func host start comando per avviare il runtime locale.

Eseguire una funzione locale

Con l'host di Funzioni locali (func.exe) in esecuzione, è ora possibile attivare singole funzioni per eseguire ed eseguire il debug del codice della funzione. Il modo in cui si esegue una singola funzione dipende dal tipo di trigger.

Nota

Gli esempi in questo argomento usano lo strumento cURL per inviare richieste HTTP dal terminale o da un prompt dei comandi. È possibile usare lo strumento preferito per inviare richieste HTTP al server locale. Lo strumento cURL è disponibile per impostazione predefinita nei sistemi basati su Linux e Windows 10 build 17063 e versioni successive. In Windows precedente è necessario prima scaricare e installare lo strumento cURL.

I trigger HTTP vengono avviati inviando una richiesta HTTP all'endpoint locale e alla porta come visualizzato nell'output func.exe, che ha questo formato generale:

http://localhost:<PORT>/api/<FUNCTION_NAME>

In questo modello di URL è <FUNCTION_NAME> il nome della funzione o della route ed <PORT> è la porta locale su cui func.exe è in ascolto.

Ad esempio, questo comando cURL attiva la MyHttpTrigger funzione di avvio rapido da una richiesta GET con il parametro name passato nella stringa di query:

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

Questo esempio è la stessa funzione chiamata da una richiesta POST che passa il nome nel corpo della richiesta, visualizzata sia per la shell Bash che per la riga di comando di Windows:

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

Quando si chiamano endpoint HTTP in locale, si applicano le considerazioni seguenti:

  • È possibile effettuare richieste GET da un browser passando dati nella stringa di query. Per tutti gli altri metodi HTTP, è necessario usare cURL, Fiddler, Postman o uno strumento di test HTTP simile che supporta le richieste POST.

  • Assicurarsi di usare lo stesso nome server e la stessa porta su cui è in ascolto l'host di Funzioni. Nell'output generato all'avvio dell'host funzione viene visualizzato un endpoint simile al seguente. È possibile chiamare questo URL usando qualsiasi metodo HTTP supportato dal trigger.

Pubblicare in Azure

Funzioni di Azure Core Tools supporta tre tipi di distribuzione:

Tipo di distribuzione Comando Descrizione
File di progetto func azure functionapp publish Distribuisce i file di progetto della funzione direttamente nell'app per le funzioni usando la distribuzione ZIP.
App contenitore di Azure func azurecontainerapps deploy Distribuisce un'app per le funzioni in contenitori in un ambiente app contenitore esistente.
Cluster Kubernetes func kubernetes deploy Distribuisce l'app per le funzioni Linux come contenitore Docker personalizzato in un cluster Kubernetes.

Per poter pubblicare in Azure da Core Tools, è necessario che sia installata l'interfaccia della riga di comando di Azure o Azure PowerShell in locale. Per impostazione predefinita, Core Tools usa questi strumenti per l'autenticazione con l'account Azure.

Se questi strumenti non sono installati, è necessario ottenere invece un token di accesso valido da usare durante la distribuzione. È possibile presentare un token di accesso usando l'opzione --access-token nei comandi di distribuzione.

Distribuire i file di progetto

Per pubblicare il codice locale in un'app per le funzioni in Azure, usare il func azure functionapp publish publish comando , come nell'esempio seguente:

func azure functionapp publish <FunctionAppName>

Questo comando pubblica i file di progetto dalla directory corrente a <FunctionAppName> come pacchetto di distribuzione .zip. Se il progetto richiede la compilazione, viene eseguito in remoto durante la distribuzione.

Java usa Maven per pubblicare il progetto locale in Azure anziché in Core Tools. Usare il comando Maven seguente per pubblicare il progetto in Azure:

mvn azure-functions:deploy

Quando si esegue questo comando, le risorse di Azure vengono create durante la distribuzione iniziale in base alle impostazioni nel file pom.xml . Per altre informazioni, vedere Distribuire il progetto di funzione in Azure.

Le considerazioni seguenti si applicano a questo tipo di distribuzione:

  • La pubblicazione sovrascrive i file esistenti nella distribuzione dell'app per le funzioni remote.

  • È necessario avere già creato un'app per le funzioni nella sottoscrizione di Azure. Core Tools distribuisce il codice del progetto in questa risorsa dell'app per le funzioni. Per informazioni su come creare un'app per le funzioni dal prompt dei comandi o dalla finestra del terminale usando l'interfaccia della riga di comando di Azure o Azure PowerShell, vedere Creare un'app per le funzioni per l'esecuzione serverless. È anche possibile creare queste risorse nel portale di Azure. Viene visualizzato un errore quando si tenta di pubblicare in un oggetto <FunctionAppName> che non esiste nella sottoscrizione.

  • Una cartella di progetto può contenere file e directory specifici della lingua che non devono essere pubblicati. Gli elementi esclusi sono elencati in un file con estensione funcignore nella cartella del progetto radice.

  • Per impostazione predefinita, il progetto viene distribuito in modo che venga eseguito dal pacchetto di distribuzione. Per disabilitare questa modalità di distribuzione consigliata, usare l'opzione --nozip.

  • Una compilazione remota viene eseguita su progetti compilati. Questa operazione può essere controllata usando l'opzione --no-build.

  • Usare l'opzione --publish-local-settings per creare automaticamente le impostazioni dell'app nell'app per le funzioni in base ai valori nel file local.settings.json.

  • Per pubblicare in uno slot denominato specifico nell'app per le funzioni, usare l'opzione --slot.

Distribuire contenitori

Core Tools consente di distribuire l'app per le funzioni in contenitori sia in ambienti di App Azure Container gestite che in cluster Kubernetes gestiti.

Usare il comando seguente func azurecontainerapps deploy per distribuire un'immagine del contenitore esistente in un ambiente app contenitore:

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

Quando si esegue la distribuzione in un ambiente di App Azure Container, si applicano le considerazioni seguenti:

  • L'ambiente e l'account di archiviazione devono già esistere. L'account di archiviazione stringa di connessione fornito viene usato dall'app per le funzioni distribuita.

  • Non è necessario creare una risorsa dell'app per le funzioni separata durante la distribuzione in App contenitore.

  • Archiviazione stringa di connessione e altre credenziali del servizio sono segreti importanti. Assicurarsi di archiviare in modo sicuro tutti i file di script usando func azurecontainerapps deploy e di non archiviarli in sistemi di controllo del codice sorgente accessibili pubblicamente. È possibile crittografare il file di local.settings.json per una maggiore sicurezza.

Per altre informazioni, vedere Hosting di app azure Container di Funzioni di Azure.

Usare le impostazioni dell'app in locale

Quando si esegue in un'app per le funzioni in Azure, le impostazioni richieste dalle funzioni vengono archiviate in modo sicuro nelle impostazioni dell'app. Durante lo sviluppo locale, queste impostazioni vengono invece aggiunte alla Values raccolta nel file local.settings.json. Il file local.settings.json archivia anche le impostazioni usate dagli strumenti di sviluppo locali.

Gli elementi nella Values raccolta nel file di local.settings.json del progetto sono destinati a eseguire il mirroring degli elementi nelle impostazioni dell'applicazione dell'app per le funzioni in Azure.

Quando si lavora con il file di impostazioni locali, si applicano le considerazioni seguenti:

  • Poiché l'local.settings.json può contenere segreti, ad esempio stringa di connessione, non è mai consigliabile archiviarlo in un repository remoto. Core Tools consente di crittografare questo file di impostazioni locali per migliorare la sicurezza. Per altre informazioni, vedere File di impostazioni locali. È anche possibile crittografare il file local.settings.json per una maggiore sicurezza.

  • Per impostazione predefinita, le impostazioni locali non vengono migrate automaticamente quando il progetto viene pubblicato in Azure. Usare l'opzione --publish-local-settings quando si pubblicano i file di progetto per assicurarsi che queste impostazioni vengano aggiunte all'app per le funzioni in Azure. I valori nella ConnectionStrings sezione non vengono mai pubblicati. È anche possibile caricare le impostazioni dal file local.settings.json in qualsiasi momento.

  • È possibile scaricare e sovrascrivere le impostazioni nel file local.settings.json con le impostazioni dell'app per le funzioni in Azure. Per altre informazioni, vedere Scaricare le impostazioni dell'applicazione.

  • I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.
  • I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.
  • I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.
  • I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.
  • I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.
  • Quando non viene impostata alcuna stringa di connessione di archiviazione valida per AzureWebJobsStorage e non viene usato un emulatore di archiviazione locale, viene visualizzato un errore. È possibile usare Core Tools per scaricare un stringa di connessione specifico da qualsiasi account Archiviazione di Azure.

Scaricare le impostazioni dell'applicazione

Dalla radice del progetto usare il comando seguente per scaricare tutte le impostazioni dell'applicazione dall'app myfunctionapp12345 in Azure:

func azure functionapp fetch-app-settings myfunctionapp12345

Questo comando sovrascrive le impostazioni esistenti nel file local.settings.json con i valori di Azure. Quando non è già presente, i nuovi elementi vengono aggiunti alla raccolta. Per altre informazioni, vedere il func azure functionapp fetch-app-settings comando .

Scaricare un stringa di connessione di archiviazione

Gli strumenti di base semplificano anche l'stringa di connessione di qualsiasi account di archiviazione a cui si ha accesso. Dalla radice del progetto usare il comando seguente per scaricare il stringa di connessione da un account di archiviazione denominato mystorage12345.

func azure storage fetch-connection-string mystorage12345

Questo comando aggiunge un'impostazione denominata mystorage12345_STORAGE al file di local.settings.json, che contiene il stringa di connessione per l'accountmystorage12345. Per altre informazioni, vedere il func azure storage fetch-connection-string comando .

Per una maggiore sicurezza durante lo sviluppo, è consigliabile crittografare il file di local.settings.json.

Caricare le impostazioni locali in Azure

Quando si pubblicano i file di progetto in Azure senza usare l'opzione --publish-local-settings , le impostazioni nel file local.settings.json non vengono impostate nell'app per le funzioni. È sempre possibile eseguire func azure functionapp publish di nuovo con l'opzione --publish-settings-only per caricare solo le impostazioni senza ripubblicare i file di progetto.

L'esempio seguente carica solo le impostazioni dalla Values raccolta nel file local.settings.json all'app per le funzioni in Azure denominata myfunctionapp12345:

func azure functionapp publish myfunctionapp12345 --publish-settings-only

Crittografare il file delle impostazioni locali

Per migliorare la sicurezza di stringa di connessione e altri dati importanti nelle impostazioni locali, Core Tools consente di crittografare il file di local.settings.json. Quando questo file viene crittografato, il runtime decrittografa automaticamente le impostazioni quando necessario allo stesso modo con l'impostazione dell'applicazione in Azure. È anche possibile decrittografare un file crittografato in locale per usare le impostazioni.

Usare il comando seguente per crittografare il file di impostazioni locali per il progetto:

func settings encrypt

Usare il comando seguente per decrittografare un'impostazione locale crittografata, in modo che sia possibile usarla:

func settings decrypt

Quando il file di impostazioni viene crittografato e decrittografato, viene aggiornata anche l'impostazione del IsEncrypted file.

Configurare le estensioni di associazione

I trigger e le associazioni di funzioni vengono implementati come pacchetti di estensione .NET (NuGet). Per poter usare un'estensione di associazione specifica, tale estensione deve essere installata nel progetto.

Questa sezione non si applica alla versione 1.x del runtime di Funzioni. Nella versione 1.x il binding supportato è stato incluso nell'estensione del prodotto principale.

Per i progetti di libreria di classi C#, aggiungere riferimenti ai pacchetti NuGet specifici per le estensioni di associazione richieste dalle funzioni. Il progetto script C# (con estensione csx) deve usare bundle di estensioni.

Funzioni fornisce bundle di estensioni per semplificare l'uso delle estensioni di binding nel progetto. I bundle di estensione, che vengono con versione e definiti nel file host.json, installano un set completo di pacchetti di estensioni di associazione compatibili per la tua app. Il host.json dovrebbe avere già bundle di estensioni abilitati. Se per qualche motivo è necessario aggiungere o aggiornare il bundle di estensione nel file host.json, vedere Bundle di estensioni.

Se è necessario usare un'estensione di associazione o una versione di estensione non in un bundle supportato, è necessario installare manualmente le estensioni. Per scenari rari, vedere il func extensions install comando .

Versioni di Core Tools

Le versioni principali di Funzioni di Azure Core Tools sono collegate a versioni principali specifiche del runtime di Funzioni di Azure. Ad esempio, la versione 4.x di Core Tools supporta la versione 4.x del runtime di Funzioni. Questa versione è la versione principale consigliata sia del runtime di Funzioni che di Core Tools. È possibile determinare la versione più recente di Core Tools nel repository Funzioni di Azure Core Tools.

Eseguire il comando seguente per determinare la versione dell'installazione corrente di Core Tools:

func --version

Se non diversamente specificato, gli esempi in questo articolo sono relativi alla versione 4.x.

Le considerazioni seguenti si applicano alle installazioni di Core Tools:

  • È possibile installare una sola versione di Core Tools in un determinato computer.

  • Quando si esegue l'aggiornamento alla versione più recente di Core Tools, è necessario usare lo stesso metodo usato per l'installazione originale per eseguire l'aggiornamento. Ad esempio, se è stata usata un'identità del servizio gestito in Windows, disinstallare l'identità del servizio gestito corrente e installarla più recente. In alternativa, se è stato usato npm, eseguire di nuovo .npm install command

  • La versione 2.x e la 3.x di Core Tools sono state usate con le versioni 2.x e 3.x del runtime di Funzioni, che hanno raggiunto la fine del supporto. Per altre informazioni, vedere Panoramica delle versioni del runtime per Funzioni di Azure.

  • La versione 1.x di Core Tools è necessaria quando si usa la versione 1.x del runtime di Funzioni, che è ancora supportata. Questa versione di Core Tools può essere eseguita solo in locale nei computer Windows. Se è attualmente in esecuzione nella versione 1.x, è consigliabile eseguire la migrazione dell'app alla versione 4.x di oggi.

Passaggi successivi

Informazioni su come sviluppare, testare e pubblicare funzioni di Azure usando Funzioni di Azure strumenti di base. Strumenti di base di Funzioni di Azure è open source ed è ospitato su GitHub. Per registrare una richiesta per un bug o una funzionalità aprire un problema di GitHub.