Funzioni di Azure runtime 1.x riferimento legacy

Importante

Il supporto è terminato per la versione 1.x dell'runtime di Funzioni di Azure il 14 settembre 2026. Eseguire la migrazione delle app alla versione 4.x per il supporto completo.

Questo articolo conserva informazioni storiche chiave e collega riferimenti dettagliati per app di funzione che utilizzano ancora runtime 1.x. Non usare runtime 1.x per le nuove app funzionali.

Ambito runtime 1.x

Funzioni di Azure runtime 1.x ha raggiunto la fine del supporto il 14 settembre 2026 e non è supportato né per le nuove né per le app di funzionalità esistenti. Runtime 1.x aveva le seguenti caratteristiche:

Funzionava solo su Windows.
Supportava app C# mirate al .NET Framework e alle app JavaScript.
Le app C# sono state eseguite in corso. Runtime 1.x non supportava il modello di worker isolato.
Utilizzava la versione 1.x di Funzioni di Azure Core Tools per lo sviluppo locale. Core Tools 1.x gira solo su Windows.
Il runtime includeva i suoi binding supportati. Le versioni runtime successive utilizzano estensioni binding o bundle di estensioni versionati separatamente.

Versioni di runtime, estensione e modello di programmazione

La versione runtime di Funzioni di Azure non è la stessa di quelle usate da binding extensions, extension bundle o modelli di programmazione linguistica. Un'etichetta di versione su un altro componente non indica che un'app utilizza il runtime di Funzioni di Azure 1.x. Per esempio:

I modelli di programmazione Python v1 e v2 girano su runtime 4.x.
I modelli di programmazione Node.js v3 e v4 girano su runtime 4.x.
Le versioni del pacchetto di extension bundle e binding sono indipendenti dalla versione runtime.

Migra a runtime 4.x

Per riportare un'app al supporto completo, migrala da runtime 1.x a runtime 4.x. La guida alla migrazione copre questi compiti:

Identifica le app che puntano a runtime 1.x.
Scegli un target supportato per C# o JavaScript.
Aggiorna il progetto, le leghe, le impostazioni dell'app e host.json file.
Testa l'app localmente e aggiorna l'app funzione in Azure.

Non cambiare solo le impostazioni dell'app FUNCTIONS_EXTENSION_VERSION . Gli aggiornamenti in runtime possono richiedere modifiche al progetto, al codice, al binding e alla configurazione.

Impostazioni specifiche dell'app per runtime 1.x

L'impostazione obsoleta AzureWebJobsDashboard è supportata solo dalla runtime 1.x. Contiene una stringa di connessione opzionale per account di archiviazione generica utilizzata per memorizzare i log e visualizzarli nella scheda Monitor del portale Azure.

Chiave	Valore di esempio
`AzureWebJobsDashboard`	`DefaultEndpointsProtocol=https;AccountName=...`

Runtime 1.x non supporta l'impostazione dell'app AZURE_FUNCTIONS_ENVIRONMENT .

Il FUNCTIONS_EXTENSION_VERSION valore ~1 fissa un'app funzione a runtime 1.x. La memoria delle chiavi nel file system (AzureWebJobsSecretStorageType=files) è la scelta predefinita.

La functionsRuntimeAdminIsolationEnabled proprietà del sito non è disponibile in runtime 1.x. L'impostazione FUNCTIONS_V2_COMPATIBILITY_MODE non si applica alle app runtime 1.x.

Project e differenze linguistiche

I progetti di libreria di classi C# 1.x in tempo reale miravano al framework .NET e utilizzavano la versione 1.x del Microsoft.NET.Sdk.Functions pacchetto. Potrebbero essere usati TraceWriter per il disboscamento. Per il modello di progetto C# attuale e le considerazioni sulla migrazione, consulta la guida per sviluppatori della libreria di classi .NET e la guida alla migrazione runtime 1.x.

Progetti di biblioteca per la classe C#

Il seguente esempio mostra le parti rilevanti di un file di progetto runtime 1.x:

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

Le Microsoft.NET.Sdk.Functions dipendenze dei pacchetti includono trigger e binding. Un progetto 1.x si riferisce a trigger e bindings 1.x perché mirano al framework .NET. Il pacchetto dipende anche da Newtonsoft.Json e indirettamente su WindowsAzure.Storage. Queste dipendenze garantiscono che il progetto utilizzi versioni compatibili con l'runtime delle Funzioni target. Ad esempio, il runtime Functions che mira a .NET Framework 4.6.1 è compatibile con la versione 9.0.1, non con Newtonsoft.Json la versione 11.

Runtime 1.x utilizzato TraceWriter per la registrazione di Application Insights. TraceWriter Non supporta la registrazione strutturata.

Il seguente esempio crea un TelemetryClient e usa TrackEvent, TrackMetric, e TrackDependency per registrare telemetria personalizzata. Utilizza anche il contesto di esecuzione della funzione per correlare la telemetria personalizzata con l'invocazione corrente.

Esempio di telemetria personalizzata

using System;
using System.Linq;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace functionapp0915
{
	public static class HttpTrigger2
	{
		private static string key = TelemetryConfiguration.Active.InstrumentationKey =
			Environment.GetEnvironmentVariable(
				"APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

		private static TelemetryClient telemetryClient =
			new TelemetryClient() { InstrumentationKey = key };

		[FunctionName("HttpTrigger2")]
		public static async Task<HttpResponseMessage> Run(
			[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
			HttpRequestMessage req, ExecutionContext context, ILogger log)
		{
			log.LogInformation("C# HTTP trigger function processed a request.");
			DateTime start = DateTime.UtcNow;
			string name = req.GetQueryNameValuePairs()
				.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
				.Value;
			dynamic data = await req.Content.ReadAsAsync<object>();
			name = name ?? data?.name;

			var evt = new EventTelemetry("Function called");
			UpdateTelemetryContext(evt.Context, context, name);
			telemetryClient.TrackEvent(evt);

			var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
			UpdateTelemetryContext(metric.Context, context, name);
			telemetryClient.TrackMetric(metric);

			var dependency = new DependencyTelemetry
			{
				Name = "GET api/planets/1/",
				Target = "swapi.co",
				Data = "https://swapi.co/api/planets/1/",
				Timestamp = start,
				Duration = DateTime.UtcNow - start,
				Success = true
			};
			UpdateTelemetryContext(dependency.Context, context, name);
			telemetryClient.TrackDependency(dependency);
		}

		private static void UpdateTelemetryContext(
			TelemetryContext context,
			ExecutionContext functionContext,
			string userName)
		{
			context.Operation.Id = functionContext.InvocationId.ToString();
			context.Operation.ParentId = functionContext.InvocationId.ToString();
			context.Operation.Name = functionContext.FunctionName;
			context.User.Id = userName;
		}
	}
}

Runtime 1.x supportava anche script C# (.csx) e funzioni JavaScript. Lo script C# non è specifico per runtime 1.x, quindi usa il riferimento dello sviluppatore script C# per indicazioni generali sugli script. Usa la guida alla migrazione per le modifiche specifiche del runtime.

Per esempi della sintassi C# precedente, vedi i template di funzione runtime 1.x.

Assembly e pacchetti script C#

Nelle funzioni di script 1.x C# in tempo reale, si potevano fare riferimento ai seguenti assembly con un semplice nome:

Newtonsoft.Json
Microsoft.WindowsAzure.Storage
Microsoft.ServiceBus
Microsoft.AspNet.WebHooks.Receivers
Microsoft.AspNet.WebHooks.Common

Runtime 1.x utilizzava un file project.json per definire dipendenze. Il seguente esempio aggiunge il Microsoft.ProjectOxford.Face pacchetto NuGet:

{
	"frameworks": {
		"net46": {
			"dependencies": {
				"Microsoft.ProjectOxford.Face": "1.1.0"
			}
		}
	}
}

I bundle di estensione non sono supportati da runtime 1.x. Per usare un feed NuGet personalizzato, specifica il feed in un file NuGet.Config nella cartella di origine dell'app funzione. Per altre informazioni, vedere Configuring NuGet behavior (Configurazione del comportamento di NuGet).

Sviluppo locale con Core Tools 1.x

La versione 1.x di Funzioni di Azure Core Tools è abbinata a runtime 1.x e gira solo su Windows. Per iniziare la runtime, eseguivi func host start. Per le attuali linee guida sullo sviluppo locale, vedi Develop Funzioni di Azure locally using Core Tools.

Visual Studio memorizzava le versioni runtime 1.x di Core Tools e %USERPROFILE%\AppData\Local\Azure.Functions.Cli utilizzava l'ultima versione memorizzata lì. Potevi vedere la versione selezionata nell'output console durante l'esecuzione del progetto:

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

Riferimento a runtime 1.x host.json

Lo schema e le impostazioni dihost.json sono cambiati dopo la runtime 1.x. Consulta il riferimento runtime 1.x host.json quando si esamina una configurazione esistente e confrontalo con il riferimento host.json corrente durante la migrazione.

Monitora le app runtime 1.x con Application Insights

Runtime 1.x utilizza le seguenti categorie di log di Application Insights:

Category	Table	Description
`Function`	traces	Log generati dall'utente, che possono essere di qualunque livello di log.
`Host.Aggregator`	customMetrics	Conteggi e medie delle invocazioni di funzioni su un periodo configurabile. Il valore predefinito è 30 secondi o 1.000 risultati, a seconda di quale si verifichi per primo. Questi log vengono scritti al livello `Information`.
`Host.Executor`	traces	Funzione avviata e completata dei log. Le esecuzioni riuscite usano `Information`, eccezioni usano `Error`, e condizioni come i messaggi poison-queue usano `Warning`.
`Host.Results`	requests	Successo o fallimento delle esecuzioni funzionali. Questi log vengono scritti al livello `Information`.

Configurare i livelli di log

Runtime 1.x configura i livelli di log sotto logger.categoryFilter in host.json:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Host.Results": "Information",
				"Host.Aggregator": "Trace",
				"Function": "Information"
			}
		}
	}
}

Quando più nomi di categorie iniziano con la stessa stringa, la categoria più specifica viene abbinata per prima. Il seguente esempio registra tutto tranne Host.Aggregator che Error al livello:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Information",
			"categoryLevels": {
				"Host": "Error",
				"Function": "Error",
				"Host.Aggregator": "Information"
			}
		}
	}
}

Configurare il campionamento

La velocità massima di telemetria predefinita è di cinque elementi al secondo. Runtime 1.x configura il campionamento sotto applicationInsights.sampling:

{
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

Il seguente esempio combina filtraggio per categorie e campionamento:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Function": "Error",
				"Host.Aggregator": "Error",
				"Host.Results": "Information",
				"Host.Executor": "Warning"
			}
		}
	},
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

Runtime 1.x non supporta la configurazione per funzione.

Capacità di Application Insights

Runtime 1.x raccoglieva automaticamente richieste, eccezioni e contatori di prestazioni. Non raccoglieva automaticamente dipendenze HTTP, bus di servizio, Event Hub o SQL. Supportava QuickPulse/Live Metrics senza un canale di controllo sicuro e supportava il campionamento, ma non supportava heartbeats, correlazione con bus di servizio o Event Hubs, né la raccolta di telemetrie completamente configurabile.

Funzionalità e comportamento non supportati in runtime 1.x

Le politiche di ritentativi non sono supportate.
Il monitoraggio dinamico su scala dei trigger di rete virtuale non è supportato.
Nei piani Premium e dedicati, il timeout predefinito di esecuzione della funzione è illimitato. Nel piano Consumo, il timeout predefinito è di cinque minuti e il massimo è di 10 minuti.
Un'app di funzioni che utilizza un pacchetto di distribuzione remota non può funzionare senza una condivisione File di Azure.

Binding inclusi in runtime 1.x

Funzioni di Azure runtime 1.x è stato ritirato. Quando migri a runtime 4.x, usa estensioni di binding attuali o un bundle di estensioni e rivedi ogni binding per le modifiche di configurazione e tipo.

I seguenti binding erano inclusi con runtime 1.x. La colonna degli attributi C# mostra i nomi brevi usati nel codice. I corrispondenti nomi delle classi hanno un Attribute suffisso, come BlobTriggerAttribute. Le funzioni di script C# definiscono invece i bindings nel filefunction.json .

Type	Grilletto	Input	Risultato	Attributi C#
gestione rete virtuale di Azure	Yes	Yes	Yes	`[BlobTrigger]` (trigger) `[Blob]` (input/output)
Azure Cosmos DB	Yes	Yes	Yes	`[CosmosDBTrigger]` (trigger) `[DocumentDB]` (input/output)
Griglia di eventi	Yes	No	No	`[EventGridTrigger]`
Centri eventi	Yes	No	Yes	`[EventHubTrigger]` (trigger) `[EventHub]` (output)
HTTP e webhook	Yes	No	Yes	`[HttpTrigger]`
hub IoT	Yes	No	No	`[EventHubTrigger]`
App per dispositivi mobili	No	Yes	Yes	`[MobileTable]`
Hub di notifica di Azure	No	No	Yes	`[NotificationHub]`
Archiviazione code	Yes	No	Yes	`[QueueTrigger]` (trigger) `[Queue]` (output)
SendGrid	No	No	Yes	`[SendGrid]`
Bus di servizio	Yes	No	Yes	`[ServiceBusTrigger]` (trigger) `[ServiceBus]` (output)
Archiviazione tabelle	No	Yes	Yes	`[Table]`
Temporizzatore	Yes	No	No	`[TimerTrigger]`
Twilio	No	No	Yes	`[TwilioSms]`

Le app di funzione che utilizzano runtime 1.x fanno automaticamente riferimento al pacchetto Microsoft.Azure. WebJobs NuGet (versione 2.x).

I trigger e i binding di gestione rete virtuale di Azure, Queue Storage e Table Storage utilizzano la versione 7.2.1 del pacchetto NuGet di WindowsAzure.Storage. Se fai riferimento a una versione diversa dell'SDK di Storage e associ a un tipo di SDK di Storage nella firma della tua funzione, l'runtime delle funzioni potrebbe segnalare che non può assegnarsi a quel tipo. Assicurati che il tuo progetto faccia riferimento a WindowsAzure.Storage 7.2.1.

gestione rete virtuale di Azure bindings in runtime 1.x

Runtime 1.x ha esposto tipi dal deprecato Microsoft. Spazio di nomi WindowsAzure.Storage. Tipi più recenti da Azure. Storage.Blob richiedono un'estensione successiva e runtime 4.x.

Binding di archiviazione in coda in runtime 1.x

Runtime 1.x ha esposto tipi dal deprecato Microsoft. Spazio di nomi WindowsAzure.Storage. Tipi più recenti da Azure. Le Storage.Queue richiedono un'estensione successiva e runtime 4.x.

Per le impostazioni di binding Storage in Coda, consulta la sezione code del riferimento runtime 1.x host.json. Nel runtime 1.x, l'impostazione maxPollingInterval è espressa in millisecondi. Nelle versioni di esecuzione successive, il suo tipo di dato è TimeSpan.

Binding di archiviazione delle tabelle in runtime 1.x

Runtime 1.x esposto tipi dal deprecato Microsoft. Spazio nominale WindowsAzure.Storage.Table. Tipi più recenti da Azure. Data.Tables richiedono l'estensione e runtime 4.x di Azure Tables.

Esempi di input

La seguente funzione C# legge una singola riga della tabella. Per ogni messaggio inviato alla coda, la funzione viene attivata. Il valore {queueTrigger} della chiave di riga associa la chiave di riga ai metadati del messaggio, ovvero la stringa del messaggio.

public class TableStorage
{
	public class MyPoco
	{
		public string PartitionKey { get; set; }
		public string RowKey { get; set; }
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition", "{queueTrigger}")] MyPoco poco,
		ILogger log)
	{
		log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
	}
}

La seguente funzione C# legge più righe di tabella dove la MyPoco classe deriva da TableEntity.

public class TableStorage
{
	public class MyPoco : TableEntity
	{
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition")] IQueryable<MyPoco> pocos,
		ILogger log)
	{
		foreach (MyPoco poco in pocos)
		{
			log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
		}
	}
}

Utilizzo degli input

Per restituire un'entità specifica per chiave, usare un parametro di associazione che deriva da TableEntity. Le specifiche TableName, PartitionKey, e RowKey sono usate per cercare di ottenere un'entità specifica dalla tabella.

Per eseguire query che restituiscono più entità, eseguire l'associazione a un IQueryable<T> di un tipo che eredita da TableEntity.

Utilizzo dell'uscita

Per i parametri e i tipi restituiti sono supportati out i tipi seguenti:

Oggetto CLR (POCO) normale che include le PartitionKey proprietà e RowKey . È possibile accompagnare queste proprietà implementando ITableEntity o ereditando TableEntity.
ICollector<T> o IAsyncCollector<T> dove T include le PartitionKey proprietà e RowKey . È possibile accompagnare queste proprietà implementando ITableEntity o ereditando TableEntity.

È anche possibile eseguire l'associazione da CloudTableStorage SDK come parametro del metodo. È quindi possibile usare tale oggetto per scrivere nella tabella.

Binding Event Hubs in runtime 1.x

Runtime 1.x includeva il binding degli Event Hub e non richiedeva un'estensione separata. Ha messo in luce il tipo Microsoft.Azure. EventHubs.EventData, già obsoleto. Trigger degli Event Hub supportati EventData, tipi JSON-serializzabili, string, e byte[] per un singolo evento, e EventData[] e string[] per un lotto. Output bindings supportati EventData, tipi JSON-serializzabili, string, e byte[].

Per un trigger o binding di output degli Event Hub in function.json, runtime 1.x utilizza la path proprietà per il nome dell'event hub. Le versioni successive in tempo reale utilizzano eventHubName. Quando il nome dell'event hub è presente anche nella stringa di connessione, quel valore sovrascrive la proprietà in tempo reale.

Il file di esecuzione 1.xhost.json utilizza un oggetto di livello superiore eventHub :

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}

Property	Default	Description
`maxBatchSize`	64	Il numero massimo degli eventi ricevuto per ogni ciclo di ricezione.
`prefetchCount`	300	Conteggio prelettura predefinito utilizzato dall'oggetto sottostante `EventProcessorHost`.
`batchCheckpointFrequency`	1	Numero di batch di eventi da elaborare prima di creare un checkpoint del cursore di Hub eventi.

Per il riferimento completo alla configurazione, vedi la eventHub sezione del riferimento runtime 1.x host.json.

Binding della Griglia di Eventi in runtime 1.x

Le versioni delle estensioni Event Grid precedenti alla 3.x non supportano lo schema CloudEvents. Per consumare questo schema, si utilizza un trigger HTTP o migra verso runtime 4.x e l'estensione Event Grid 3.x.

Il binding di output Event Grid è disponibile solo per runtime 2.x e successivi.

Tipi di associazioni

L'estensione runtime 1.x supporta i seguenti tipi di parametri. Non supporta lo schema CloudEvents, che richiede l'estensione Event Grid 3.x.

Binding	Tipi di parametro
Trigger Griglia di eventi	`Newtonsoft.Json.Linq.JObject` `string`

Utilizzo dei trigger

Le funzioni della libreria di classi C# in processo supportano i seguenti tipi di trigger della Griglia Eventi:

Newtonsoft.Json.Linq.JObject
System.String

Endpoint Webhook e chiave di sistema

L'endpoint webhook ospitato per un trigger runtime 1.x Event Grid utilizza il seguente schema URL:

https://{functionappname}.azurewebsites.net/admin/extensions/EventGridExtensionConfig?functionName={functionname}&code={systemkey}

Per ottenere la chiave di sistema Event Grid dall'API amministratore, usa la chiave principale dell'app funzione nella seguente richiesta:

https://{functionappname}.azurewebsites.net/admin/host/systemkeys/eventgridextensionconfig_extension?code={masterkey}

Per i test locali, l'endpoint di trigger Event Grid utilizza il seguente schema URL:

http://localhost:7071/admin/extensions/EventGridExtensionConfig?functionName={FUNCTION_NAME}

Binding bus di servizio in runtime 1.x

Runtime 1.x ha esposto tipi dal decaduto spazio di nomi Microsoft. ServiceBus.Message. Tipi più recenti da Azure. Messaging.ServiceBus richiede l'estensione bus di servizio 5.x o successiva e runtime 4.x.

Il 30 settembre 2026, le librerie SDK di bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure. ServiceBus e com.microsoft.azure. ServiceBus andranno in pensione. Queste librerie non rispettano le linee guida di Azure SDK. Il supporto per il bus di servizio Messaging Protocol (SBMP) terminerà anch'esso. Anche se puoi continuare a usare le librerie più vecchie dopo il pensionamento, non riceveranno più supporto ufficiale né aggiornamenti da Microsoft. Per ulteriori informazioni, consultare l'annuncio relativo all'interruzione del supporto.

Utilizzo dei trigger

Il trigger del messaggio della coda o dell'argomento supporta i seguenti tipi di parametri:

BrokeredMessage ti fornisce il messaggio deerializzato con il metodo BrokeredMessage.GetBody<T>( ).
MessageReceiver riceve e conferma i messaggi dal contenitore dei messaggi. Questo tipo è richiesto quando autoComplete è impostato a false.

Nelle librerie di classi C#, il costruttore dell'attributo assume il nome della coda oppure dell'argomento e dell'abbonamento. Puoi anche specificare i diritti di accesso della connessione. Se i diritti di accesso non vengono specificati, l'impostazione predefinita è Manage.

Selezione account bus di servizio

Usa ServiceBusAccountAttribute per specificare l'account bus di servizio. Il costruttore accetta il nome di un'impostazione dell'app che contiene un bus di servizio stringa di connessione. Applica l'attributo a livello di parametro, metodo o classe. Il seguente esempio mostra attributi a livello di classe e a livello di metodo:

[ServiceBusAccount("ClassLevelServiceBusAppSetting")]
public static class AzureFunctions
{
	[ServiceBusAccount("MethodLevelServiceBusAppSetting")]
	[FunctionName("ServiceBusQueueTriggerCSharp")]
	public static void Run(
		[ServiceBusTrigger("myqueue", AccessRights.Manage)]
		string myQueueItem, ILogger log)
	{
		// ...
	}
}

Il seguente ordine determina quale account bus di servizio utilizzare:

La proprietà ServiceBusTrigger dell'attributo Connection.
L'attributo ServiceBusAccount applicato allo stesso parametro dell'attributo ServiceBusTrigger.
L'attributo ServiceBusAccount applicato alla funzione.
L'attributo ServiceBusAccount applicato alla classe.
Impostazione dell'app AzureWebJobsServiceBus .

Metadati del messaggio

Le seguenti proprietà sono membri delle classi BrokeredMessage e MessageReceiver .

Property	Type	Description
`ContentType`	`string`	Un identificatore di tipo di contenuto usato dal mittente e dal destinatario per la logica specifica dell'applicazione.
`CorrelationId`	`string`	L'ID di correlazione,
`DeadLetterSource`	`string`	La fonte di lettura morta.
`DeliveryCount`	`Int32`	Il numero di recapiti.
`EnqueuedTimeUtc`	`DateTime`	Il tempo in coda in Tempo Universale Coordinato (UTC).
`ExpiresAtUtc`	`DateTime`	L'ora di scadenza in formato UTC.
`Label`	`string`	Etichetta specifica dell'applicazione.
`MessageId`	`string`	Valore definito dall'utente che bus di servizio possibile usare per identificare i messaggi duplicati, se abilitati.
`MessageReceiver`	`MessageReceiver`	bus di servizio ricevitore di messaggi. Può essere usato per abbandonare, completare o usare il messaggio senza precedenti.
`MessageSession`	`MessageSession`	Ricevitore di messaggi specifico per le code e gli argomenti abilitati per la sessione.
`ReplyTo`	`string`	L'indirizzo della coda di risposta.
`SequenceNumber`	`long`	Numero univoco assegnato a un messaggio dal bus di servizio.
`To`	`string`	L'indirizzo di invio.
`UserProperties`	`IDictionary<string, object>`	Proprietà impostate dal mittente.

Utilizzo dell'uscita

Usare il tipo BrokeredMessage quando si inviano messaggi con metadati. Definisci i parametri come return attributi di tipo. Se il valore del parametro è nullo quando la funzione esce, Functions non crea un messaggio.

Per function.json vincola, accessRights accetta manage o listen e predefinito a manage. Se la stringa di connessione non ha il permesso di gestione, imposta accessRights per listen impedire al runtime di tentare operazioni di gestione.

L'runtime crea la coda se non esiste e imposti accessRights .manage

Impostazioni host

Per bus di servizio impostazioni di assegnazione, vedi il riferimento runtime 1.x host.json.

Binding HTTP e webhook in runtime 1.x

Una funzione attivata da HTTP restituisce HTTP 200 OK di default un corpo vuoto. Le versioni runtime successive restituiscono HTTP 204 No Content.

Per un trigger HTTP in function.json, usa la webHookType proprietà per configurare il trigger affinché funzioni come ricevitore webhook per il provider specificato. Questa proprietà è specifica per runtime 1.x.

Runtime 1.x non supporta l'accesso alle informazioni client autenticate.

Modalità Webhook

I template di Webhook forniscono una validazione aggiuntiva per i payload di Webhook. La webHookType proprietà di binding mostra il fornitore del webhook e controlla il payload supportato:

Valore del tipo	Description
`genericJson`	Endpoint di webhook per uso generico senza logica per un provider specifico. Questa impostazione limita le richieste a HTTP POST con il tipo di `application/json` contenuto.
`github`	La funzione risponde ai webhook GitHub. Non usare la `authLevel` proprietà con webhook GitHub.
`slack`	La funzione risponde ai webhook Slack. Non usare la `authLevel` proprietà con webhook Slack.

Quando imposta webHookType, non impostare la methods proprietà.

Per rispondere ai webhook di GitHub, crea la funzione con un trigger HTTP, imposta webHookType su github, e copia il suo URL e la chiave API nella pagina Aggiungi webhook del repository GitHub.

Il webhook di Slack genera un token, quindi configura una chiave specifica per la funzione con quel token.

Il componente ricevitore webhook gestisce l'autorizzazione webhook. Il meccanismo varia a seconda del tipo di webhook, ma ogni meccanismo si basa su una chiave. Di default, viene utilizzata la chiave funzione nominata default . Per usare un'altra chiave, configura il fornitore del webhook per inviare il nome della chiave in uno dei seguenti modi:

Nel parametro clientid della stringa di interrogazione, come https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
Nell'intestazione x-functions-clientid della richiesta.

Per le impostazioni di binding HTTP, consulta la sezione HTTP del riferimento runtime 1.x host.json.

Trigger di riscaldamento in runtime 1.x

Runtime 1.x non supporta il trigger di riscaldamento.

Binding di SendGrid in runtime 1.x

Aggiungere l'estensione al progetto installando il pacchetto NuGet versione 2.x.

Per le impostazioni di binding SendGrid, vedi la sezione SendGrid del riferimento runtime 1.x host.json.

Binding Twilio in runtime 1.x

Aggiungere l'estensione al progetto installando il pacchetto NuGet versione 1.x.

Per la runtime 1.x, usa le seguenti proprietà di configurazione di binding nel file function.json :

Proprietà di function.json	Description
type	Impostare su `twilioSms`.
direzione	Impostare su `out`.
nome	Nome della variabile usato nel codice della funzione per il messaggio SMS di Twilio.
accountSid	Imposta il nome di un'impostazione dell'app che contiene il Sid del tuo account Twilio (`TwilioAccountSid`). Se non è impostato, il nome dell'impostazione predefinita dell'app è `AzureWebJobsTwilioAccountSid`.
authToken	Imposta il nome di un'impostazione dell'app che contiene il tuo token di autenticazione Twilio (`TwilioAccountAuthToken`). Se non è impostato, il nome dell'impostazione predefinita dell'app è `AzureWebJobsTwilioAuthToken`.
to	Imposta il numero di telefono a cui viene inviato il messaggio SMS.
da	Imposta il numero di telefono da cui viene inviato il messaggio SMS.
body	Usa il codice fisso del messaggio SMS se non devi impostarlo dinamicamente nel codice della tua funzione.

Usa le informazioni vincolanti conservate in questo articolo solo per comprendere un'app esistente. Segui la guida alla migrazione in tempo di esecuzione e la documentazione di binding attuale quando aggiorni l'app.

Domande frequenti

Funzioni di Azure runtime 1.x è ancora supportato?

No. Il supporto per Funzioni di Azure runtime 1.x è terminato il 14 settembre 2026. Migra le app interessate a runtime 4.x per un supporto completo.

Un modello di programmazione Python v1 o Node.js v4 usa runtime 1.x?

No. Le versioni dei modelli di programmazione linguistica sono indipendenti dalla versione runtime. I modelli di programmazione Python v1 e v2 e i modelli di programmazione Node.js v3 e v4 girano su runtime 4.x.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-09-18

Funzioni di Azure runtime 1.x riferimento legacy

Ambito runtime 1.x

Versioni di runtime, estensione e modello di programmazione

Migra a runtime 4.x

Impostazioni specifiche dell'app per runtime 1.x

Project e differenze linguistiche

Progetti di biblioteca per la classe C#

Esempio di telemetria personalizzata

Assembly e pacchetti script C#

Sviluppo locale con Core Tools 1.x

Riferimento a runtime 1.x host.json

Monitora le app runtime 1.x con Application Insights

Configurare i livelli di log

Configurare il campionamento

Capacità di Application Insights

Funzionalità e comportamento non supportati in runtime 1.x

Binding inclusi in runtime 1.x

gestione rete virtuale di Azure bindings in runtime 1.x

Binding di archiviazione in coda in runtime 1.x

Binding di archiviazione delle tabelle in runtime 1.x

Esempi di input

Utilizzo degli input

Utilizzo dell'uscita

Binding Event Hubs in runtime 1.x

Binding della Griglia di Eventi in runtime 1.x

Tipi di associazioni

Utilizzo dei trigger

Endpoint Webhook e chiave di sistema

Binding bus di servizio in runtime 1.x

Utilizzo dei trigger

Selezione account bus di servizio

Metadati del messaggio

Utilizzo dell'uscita

Impostazioni host

Binding HTTP e webhook in runtime 1.x

Modalità Webhook

Trigger di riscaldamento in runtime 1.x

Binding di SendGrid in runtime 1.x

Binding Twilio in runtime 1.x

Domande frequenti

Funzioni di Azure runtime 1.x è ancora supportato?

Un modello di programmazione Python v1 o Node.js v4 usa runtime 1.x?

" output is necessary.)

Commenti e suggerimenti

Risorse aggiuntive