Referência legada do Azure Functions runtime 1.x

Importante

O suporte foi encerrado para a versão 1.x do runtime do Azure Functions em 14 de setembro de 2026. Migre seus aplicativos para a versão 4.x para obter suporte completo.

Este artigo preserva informações históricas importantes e faz links para referências detalhadas de aplicativos de função que ainda utilizam o runtime 1.x. Não use o runtime 1.x para novos aplicativos de função.

Escopo de tempo de execução 1.x

O runtime do Azure Functions 1.x chegou ao fim do suporte em 14 de setembro de 2026 e não é suportado para aplicativos de funções novos ou existentes. Runtime 1.x apresentava as seguintes características:

• Ele rodava apenas no Windows.
• Ele suportava aplicativos C# que tinham como alvo o .NET Framework e aplicativos JavaScript.
• Aplicativos C# rodavam em processo. O runtime 1.x não suportava o modelo de trabalhador isolado.
• Ele utilizava a versão 1.x do Azure Functions Core Tools para desenvolvimento local. O Core Tools 1.x roda apenas no Windows.
• O runtime incluía suas ligações suportadas. Versões posteriores em tempo de execução usam extensões de binding separadamente versionadas ou pacotes de extensão.

Versões de modelos em tempo de execução, extensão e programação

A versão em tempo de execução do Azure Functions não é a mesma que as versões usadas por extensões de binding, pacotes de extensões ou modelos de programação de linguagem. Um rótulo de versão em outro componente não indica que um app usa runtime do Azure Functions 1.x. Por exemplo:

• Os modelos de programação Python v1 e v2 rodam em runtime 4.x.
• Os modelos de programação Node.js v3 e v4 rodam em runtime 4.x.
• As versões do pacote de extensão e do pacote de extensão binding são independentes da versão em tempo de execução.

Migrar para o runtime 4.x

Para devolver um app ao suporte completo, migre do runtime 1.x para o runtime 4.x. O guia de migração cobre as seguintes tarefas:

• Identifique aplicativos que têm como alvo o runtime 1.x.
• Escolha um destino suportado para C# ou JavaScript.
• Atualize o projeto, as ligações, as configurações do aplicativo e host.json arquivo.
• Teste o app localmente e atualize o app de funções no Azure.

Não mude só as FUNCTIONS_EXTENSION_VERSION configurações do app. Atualizações em tempo de execução podem exigir mudanças de projeto, código, binding e configuração.

Configurações específicas do app para runtime 1.x

A configuração obsoleta AzureWebJobsDashboard é suportada apenas pela versão 1.x em tempo de execução. Ele contém uma cadeia de conexão opcional de conta de armazenamento de uso geral, usada para armazenar logs e exibi-los na aba Monitor do portal Azure.

Chave	Valor de amostra
AzureWebJobsDashboard	DefaultEndpointsProtocol=https;AccountName=...

O runtime 1.x não suporta a AZURE_FUNCTIONS_ENVIRONMENT configuração do app.

O FUNCTIONS_EXTENSION_VERSION valor ~1 fixa um aplicativo de função no runtime 1.x. O armazenamento de chaves no sistema de arquivos (AzureWebJobsSecretStorageType=files) é o padrão.

A functionsRuntimeAdminIsolationEnabled propriedade do site não está disponível no runtime 1.x. A FUNCTIONS_V2_COMPATIBILITY_MODE configuração não se aplica a aplicativos em tempo de execução 1.x.

Project e diferenças linguísticas

Projetos de bibliotecas de classes C# 1.x em tempo de execução tinham como alvo o .NET Framework e usavam a versão 1.x do Microsoft.NET.Sdk.Functions pacote. Eles poderiam usar TraceWriter para desmatamento. Para considerar o modelo de projeto e migração do projeto C# atual, veja o guia para desenvolvedores da biblioteca de classes .NET e o guia de migração do runtime 1.x.

Projetos de bibliotecas de classe C#

O exemplo a seguir mostra as partes relevantes de um arquivo de projeto 1.x em tempo de execução:

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

As Microsoft.NET.Sdk.Functions dependências de pacotes incluem gatilhos e bindings. Um projeto 1.x refere-se a gatilhos e bindings 1.x porque eles têm como alvo o Framework .NET. O pacote também depende e Newtonsoft.Json indiretamente de WindowsAzure.Storage. Essas dependências garantem que o projeto utilize versões compatíveis com o runtime das Funções. Por exemplo, o runtime Functions que direciona o .NET Framework 4.6.1 é compatível com a versão 9.0.1, não com Newtonsoft.Json a versão 11.

Runtime 1.x usado TraceWriter para registro de Insights de Aplicação. TraceWriter Não suporta registro estruturado.

O exemplo a seguir cria um TelemetryClient e usa TrackEvent, TrackMetric, e TrackDependency para registrar telemetria personalizada. Também utiliza o contexto de execução da função para correlacionar a telemetria personalizada com a invocação atual.

Exemplo de telemetria personalizada

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;
		}
	}
}

O Runtime 1.x também suportava script C# (.csx) e funções JavaScript. O script C# não é específico para runtime 1.x, então use a referência do desenvolvedor de script C# para orientações gerais de script. Use o guia de migração para mudanças específicas de runtime.

Para exemplos da sintaxe C# anterior, veja os templates de função runtime 1.x.

Assemblies e pacotes de scripts C#

Em funções de script 1.x C# em tempo de execução, você pode referenciar os seguintes assemblies por nome simples:

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

O runtime 1.x usava um arquivo project.json para definir dependências. O exemplo a seguir adiciona o Microsoft.ProjectOxford.Face pacote NuGet:

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

Pacotes de extensão não são suportados pelo runtime 1.x. Para usar um feed NuGet personalizado, especifique o feed em um arquivo NuGet.Config na pasta raiz do app Function. Para obter mais informações, consulte Configurando o comportamento do NuGet.

Desenvolvimento local com Core Tools 1.x

A versão 1.x do Azure Functions Core Tools é pareada com o runtime 1.x e roda somente no Windows. Para iniciar a execução, você executou func host start. Para orientações atuais de desenvolvimento local, veja Develop Azure Functions locally using Core Tools.

O Visual Studio armazenava versões %USERPROFILE%\AppData\Local\Azure.Functions.Cli do Core Tools 1.x em tempo de execução e usava a versão mais recente armazenada lá. Você podia ver a versão selecionada na saída do console ao rodar o projeto:

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

Referência de host.json de runtime 1.x

O esquemahost.json e as configurações mudaram após o runtime 1.x. Veja a referência de host.json 1.x em tempo de execução ao revisar uma configuração existente e compare com a referência atual de host.json durante a migração.

Monitore aplicativos em tempo de execução 1.x com Application Insights

Runtime 1.x utiliza as seguintes categorias de log do Application Insights:

Categoria	Table	Description
Function	traces	Logs gerados pelo usuário, que podem ser de qualquer nível de log.
Host.Aggregator	customMetrics	Contagens e médias de invocações de funções ao longo de um período configurável. O padrão é 30 segundos ou 1.000 resultados, o que vier primeiro. Esses logs são gravados no nível de Information.
Host.Executor	traces	Função iniciada e concluída dos registros. Execuções bem-sucedidas usam Information, exceções usam Error, e condições como mensagens poison-queue usam Warning.
Host.Results	Solicitações	Sucesso ou fracasso da execução de funções. Esses logs são gravados no nível de Information.

Configurar os níveis de log

Runtime 1.x configura níveis de log em logger.categoryFilterhost.json:

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

Quando vários nomes de categorias começam com a mesma cadeia, a categoria mais específica é combinada primeiro. O exemplo a seguir registra tudo, exceto Host.Aggregator no nível Error :

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

Configurar a amostragem

A taxa máxima padrão de telemetria é de cinco itens por segundo. Runtime 1.x configura amostragens em:applicationInsights.sampling

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

O exemplo a seguir combina filtragem por categorias e amostragem:

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

O runtime 1.x não suporta configuração por função.

Capacidades de Insights de Aplicação

O runtime 1.x coletava automaticamente requisições, exceções e contadores de desempenho. Ele não coletava automaticamente dependências de HTTP, Barramento de Serviço, Event Hubs ou SQL. Ele suportava QuickPulse/Live Metrics sem um canal de controle seguro e suportava amostragem, mas não suportava batimentos cardíacos, correlação com Barramento de Serviço ou Event Hubs, nem coleta de telemetria totalmente configurável.

Recursos e comportamento não suportados em runtime 1.x

• Políticas de retentativas não são suportadas.
• O monitoramento em escala dinâmica dos gatilhos da rede virtual não é suportado.
• Nos planos Premium e Dedicados, o tempo padrão de execução da função é ilimitado. No plano de Consumo, o tempo padrão é de cinco minutos e o máximo é de 10 minutos.
• Um aplicativo de funções que usa um pacote de implantação remota não pode rodar sem um compartilhamento do Arquivos do Azure.

Ligações incluídas em runtime 1.x

O runtime do Azure Functions 1.x está aposentado. Quando migrar para o runtime 4.x, use extensões de binding atuais ou um pacote de extensões e revise cada binding para mudanças de configuração e tipo.

As seguintes ligações foram incluídas no runtime 1.x. A coluna de atributo C# mostra os nomes curtos usados no código. Os nomes correspondentes das classes possuem um Attribute sufixo, como BlobTriggerAttribute. Funções de script C#, em vez disso, definem bindings no arquivofunction.json .

Tipo	Trigger	Entrada	Saída	Atributos em C#
Armazenamento de Blobs	Yes	Yes	Yes	[BlobTrigger] (gatilho) [Blob] (entrada/saída)
Azure Cosmos DB	Yes	Yes	Yes	[CosmosDBTrigger] (gatilho) [DocumentDB] (entrada/saída)
Grade de Eventos	Yes	Não	Não	[EventGridTrigger]
Hubs de Eventos	Yes	Não	Yes	[EventHubTrigger] (gatilho) [EventHub] (saída)
HTTP e webhooks	Yes	Não	Yes	[HttpTrigger]
Hub IoT	Yes	Não	Não	[EventHubTrigger]
Aplicativos móveis	Não	Yes	Yes	[MobileTable]
Hubs de Notificação	Não	Não	Yes	[NotificationHub]
Armazenamento de Filas	Yes	Não	Yes	[QueueTrigger] (gatilho) [Queue] (saída)
SendGrid	Não	Não	Yes	[SendGrid]
Barramento de Serviço	Yes	Não	Yes	[ServiceBusTrigger] (gatilho) [ServiceBus] (saída)
Armazenamento de Tabelas	Não	Yes	Yes	[Table]
Timer	Yes	Não	Não	[TimerTrigger]
Twilio	Não	Não	Yes	[TwilioSms]

Aplicativos de funções que usam runtime 1.x referenciam automaticamente o pacote Microsoft.Azure. Pacote NuGet do WebJobs (versão 2.x).

Os gatilhos e vinculações Armazenamento de Blobs, Queue Storage e Table Storage usam a versão 7.2.1 do pacote NuGet do WindowsAzure.Storage. Se você referenciar uma versão diferente do SDK de Armazenamento e vincular a um tipo de SDK de Armazenamento na sua assinatura de função, o runtime das Funções pode informar que não consegue se vincular a esse tipo. Certifique-se de que seu projeto faça referência ao WindowsAzure.Storage 7.2.1.

Armazenamento de Blobs bindings em runtime 1.x

Runtime 1.x exposto tipos do espaço nominal Microsoft. WindowsAzure.Storage. Tipos mais recentes do Azure. Storage.Blobs requerem uma extensão posterior e runtime 4.x.

Vinculações de armazenamento em fila em runtime 1.x

Runtime 1.x exposto tipos do espaço nominal Microsoft. WindowsAzure.Storage. Tipos mais novos do Azure. Storage.Queues exigem uma extensão posterior e runtime 4.x.

Para as configurações de vinculação de armazenamento em fila, veja a seção de filas da referência de tempo de execução 1.x host.json. No tempo de execução 1.x, a maxPollingInterval configuração é expressa em milissegundos. Em versões posteriores em tempo de execução, seu tipo de dado é TimeSpan.

Vinculações de armazenamento de tabela em tempo de execução 1.x

O tempo de execução 1.x exposto tipos do espaço nominal obsoleto da Microsoft. WindowsAzure.Storage.Table. Tipos mais recentes do Azure. Data.Tables requerem a extensão e runtime 4.x do Azure Tablets.

Exemplos de entrada

A função C# a seguir lê uma única linha de tabela. Para cada mensagem enviada à fila, a função é acionada. O valor da chave de {queueTrigger} linha associa a chave de linha aos metadados da mensagem, que é a cadeia de caracteres da mensagem.

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}");
	}
}

A função C# a seguir lê múltiplas linhas de tabela onde a MyPoco classe deriva de 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}");
		}
	}
}

Uso de entrada

Para retornar uma entidade específica por chave, use um parâmetro de associação derivado de TableEntity. Os específicos TableName, PartitionKey, e RowKey são usados para tentar obter uma entidade específica da tabela.

Para executar consultas que retornam várias entidades, associe a um IQueryable<T> de um tipo que herda de IQueryable<T>.

Uso da saída

Os tipos a seguir têm suporte para tipos de retorno e parâmetros out:

• Um POCO (Objeto Plain Old CLR) que inclui as propriedades PartitionKey e RowKey. É possível acompanhar essas propriedades implementando ITableEntity ou herdando TableEntity.
• ICollector<T> ou IAsyncCollector<T> onde T inclui as propriedades PartitionKey e RowKey. É possível acompanhar essas propriedades implementando ITableEntity ou herdando TableEntity.

Você também pode associar a CloudTablepartir do SDK de Armazenamento como um parâmetro de método. Esse objeto pode ser usado para gravar na tabela.

Ligações de Hub de Eventos em runtime 1.x

O runtime 1.x incluía a vinculação dos Hubs de Eventos e não exigia uma extensão separada. Ele expôs o tipo obsoleto Microsoft.Azure. EventHubs.EventData. Gatilhos de Hubs de Eventos suportados EventData, tipos serializáveis em JSON, string, e byte[] para um único evento, e EventData[] e string[] para um lote. Vinculações de saída suportadas EventData, tipos serializáveis em JSON, string, e byte[].

Para um disparo ou vinculação de saída do Event Hubs em function.json, runtime 1.x usa a path propriedade do nome do hub de eventos. Versões posteriores em tempo de execução usam eventHubName. Quando o nome do hub de eventos também está presente na cadeia de conexão, esse valor sobrescreve a propriedade em tempo de execução.

O arquivo de host.json 1.x em tempo de execução usa um objeto de nível superior eventHub :

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

Property	Default	Description
maxBatchSize	64	A contagem máxima de eventos recebidos por loop de recebimento.
prefetchCount	300	A contagem da pré-busca padrão usada pelo EventProcessorHost subjacente.
batchCheckpointFrequency	1	O número de lotes de eventos a serem processados antes de criar um ponto de verificação do cursor dos Hubs de Eventos.

Para a referência completa de configuração, veja a eventHub seção da referência de host.json 1.x em tempo de execução.

Vinculações de grade de eventos em tempo de execução 1.x

Versões da extensão Event Grid anteriores à 3.x não suportam o esquema CloudEvents. Para consumir esse esquema, use um gatilho HTTP ou migre para o runtime 4.x e a extensão Event Grid 3.x.

A vinculação de saída da Grade de Eventos está disponível apenas para runtime 2.x e posteriores.

Tipos de associação

A extensão 1.x em tempo de execução suporta os seguintes tipos de parâmetros. Ele não suporta o esquema CloudEvents, que requer a extensão Event Grid 3.x.

Associação	Tipos de parâmetro
Gatilho da Grade de Eventos	Newtonsoft.Json.Linq.JObject string

Uso de gatilho

As funções da biblioteca de classes C# em processo suportam os seguintes tipos de gatilho da Grade de Eventos:

• Newtonsoft.Json.Linq.JObject
• System.String

Endpoint Webhook e chave do sistema

O endpoint hospedado do webhook para um gatilho da Grade de Eventos 1.x em tempo de execução usa o seguinte padrão de URL:

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

Para obter a chave do sistema Grade de Eventos da API do administrador, use a chave mestra do app de função na seguinte solicitação:

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

Para testes locais, o endpoint de gatilho da Grade de Eventos usa o seguinte padrão de URL:

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

Ligações do Barramento de Serviço em tempo de execução 1.x

O tempo de execução 1.x exposto tipos do espaço de nomes obsoleto da Microsoft. ServiceBus.Messenger. Tipos mais recentes do Azure. Mensaging.ServiceBus requer extensão Barramento de Serviço 5.x ou posterior e runtime 4.x.

Em 30 de setembro de 2026, as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure. ServiceBus e com.microsoft.Azure. ServiceBus serão aposentadas. Essas bibliotecas não seguem as diretrizes do SDK do Azure. O suporte ao Barramento de Serviço Messaging Protocol (SBMP) também será encerrado. Embora você possa continuar usando as bibliotecas antigas após a aposentadoria, elas não receberão mais suporte oficial nem atualizações da Microsoft. Para obter mais informações, confira o anúncio de desativação do suporte.

Uso de gatilho

O gatilho da mensagem de fila ou tópico suporta os seguintes tipos de parâmetros:

• O BrokeredMessage te dá a mensagem desserializada com o método BrokeredMessage.GetBody<T>( ).
• O MessageReceiver recebe e confirma mensagens do contêiner de mensagens. Esse tipo é necessário quando autoComplete está definido como false.

Nas bibliotecas de classes C#, o construtor do atributo assume o nome da fila ou o tópico e a assinatura. Você também pode especificar os direitos de acesso da conexão. Se você não especificar os direitos de acesso, o padrão é Manage.

Seleção de conta do Barramento de Serviço

Use o ServiceBusAccountAttribute para especificar a conta do Barramento de Serviço. O construtor usa o nome de uma configuração de aplicativo que contém um Barramento de Serviço cadeia de conexão. Aplique o atributo no nível do parâmetro, método ou classe. O exemplo a seguir mostra atributos em nível de classe e método:

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

A ordem a seguir determina qual conta do Barramento de Serviço usar:

1. A propriedade ServiceBusTrigger do atributoConnection.
2. O ServiceBusAccount atributo aplicado ao mesmo parâmetro do ServiceBusTrigger atributo.
3. O ServiceBusAccount atributo aplicado à função.
4. O ServiceBusAccount atributo aplicado à classe.
5. A AzureWebJobsServiceBus configuração do aplicativo.

Metadados da mensagem

As propriedades a seguir são membros das classes BrokeredMessage e MessageReceiver .

Property	Tipo	Description
ContentType	string	Um identificador de tipo de conteúdo usado pelo remetente e pelo receptor para lógica específica da aplicação.
CorrelationId	string	A ID de correlação.
DeadLetterSource	string	A fonte sem saída.
DeliveryCount	Int32	Número total de entregas.
EnqueuedTimeUtc	DateTime	O tempo enfileirado em Tempo Universal Coordenado (UTC).
ExpiresAtUtc	DateTime	Tempo de expiração em UTC.
Label	string	Rótulo específico do aplicativo.
MessageId	string	Um valor definido pelo usuário que Barramento de Serviço pode usar para identificar mensagens duplicadas, se habilitado.
MessageReceiver	MessageReceiver	Barramento de Serviço receptor de mensagem. Pode ser usado para abandonar, completar ou deixar a mensagem sem saída.
MessageSession	MessageSession	Um receptor de mensagens especificamente para filas e tópicos habilitados para sessão.
ReplyTo	string	O endereço da fila de resposta.
SequenceNumber	long	O número exclusivo atribuído a uma mensagem pelo Barramento de Serviço.
To	string	O endereço de envio.
UserProperties	IDictionary<string, object>	Propriedades definidas pelo remetente.

Uso da saída

Use o tipo BrokeredMessage ao enviar mensagens com metadados. Defina parâmetros como return atributos de tipo. Se o valor do parâmetro for nulo quando a função sair, Functions não cria uma mensagem.

Para function.json vincula, accessRights aceita manage ou listen e tem por padrão para manage. Se a cadeia de conexão não tiver permissão de gerenciamento, defina accessRights para listen impedir que o runtime tente operações de gerenciamento.

O tempo de execução cria a fila se ela não existir e você definir accessRights para manage.

Configurações do host

Para configurações de Barramento de Serviço binding, veja a referência de runtime 1.x host.json.

Vinculações HTTP e webhook em runtime 1.x

Uma função acionada por HTTP retorna HTTP 200 OK com o corpo vazio por padrão. Versões posteriores em tempo de execução retornam HTTP 204 No Content.

Para um gatilho HTTP em function.json, use a webHookType propriedade para configurar o gatilho para atuar como receptor webhook para o provedor especificado. Essa propriedade é específica para o runtime 1.x.

O runtime 1.x não suporta acesso a informações autenticadas do cliente.

Modo Webhook

Modelos de webhook fornecem validação extra para payloads de webhooks. A webHookType propriedade de vinculação mostra o provedor do webhook e controla a carga útil suportada:

Tipo de valor	Description
genericJson	Um ponto de extremidade de webhook de finalidade geral sem lógica para um provedor específico. Essa configuração restringe as requisições a HTTP POST com o tipo de application/json conteúdo.
github	A função responde a webhooks do GitHub. Não use a propriedade authLevel com webhooks do GitHub.
slack	A função responde a webhooks do Slack. Não use a propriedade authLevel com webhooks do Slack.

Quando você definir webHookType, não defina a methods propriedade.

Para responder aos webhooks do GitHub, crie a função com um gatilho HTTP, defina webHookType para github, e copie sua URL e chave API para a página Adicionar webhook do repositório GitHub.

O webhook do Slack gera um token, então configure uma chave específica para função com esse token.

O componente receptor webhook cuida da autorização webhook. O mecanismo varia conforme o tipo de webhook, mas cada mecanismo depende de uma chave. Por padrão, a chave de função nomeada default é usada. Para usar outra chave, configure o provedor do webhook para enviar o nome da chave de uma das seguintes formas:

• No clientid parâmetro de sequência de consulta, como https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
• No x-functions-clientid cabeçalho do pedido.

Para configurações de binding HTTP, veja a seção HTTP da referência de host.json runtime 1.x.

Gatilho de aquecimento em runtime 1.x

Runtime 1.x não suporta o gatilho de aquecimento.

Vinculação do SendGrid em tempo de execução 1.x

Adicione a extensão ao seu projeto instalando o pacote NuGet, versão 2.x.

Para as configurações de vinculação do SendGrid, veja a seção SendGrid da referência de tempo 1.x host.json.

Vinculação do Twilio em runtime 1.x

Adicione a extensão ao seu projeto instalando o pacote NuGet, versão 1.x.

Para runtime 1.x, use as seguintes propriedades de configuração de binding no arquivofunction.json :

Propriedade function.json	Description
type	Defina como twilioSms.
Direção	Defina como out.
name	Nome da variável usada no código de função para a mensagem de texto SMS do Twilio.
accountSid	Defina para o nome de uma configuração de aplicativo que guarda o Sid da sua Conta Twilio (TwilioAccountSid). Se não estiver configurado, o nome da configuração do aplicativo padrão será AzureWebJobsTwilioAccountSid.
authToken	Defina para o nome de uma configuração de aplicativo que armazena seu token de autenticação Twilio (TwilioAccountAuthToken). Se não estiver configurado, o nome da configuração do aplicativo padrão será AzureWebJobsTwilioAuthToken.
to	Defina para o número de telefone para o qual a mensagem SMS é enviada.
from	Defina para o número de telefone de onde a mensagem SMS é enviada.
body	Use para codificar diretamente a mensagem de texto se não precisar configurá-la dinamicamente no código da sua função.

Use as informações de vinculação preservadas neste artigo apenas para entender um aplicativo existente. Siga o guia de migração em tempo de execução e a documentação de vinculação atual ao atualizar o app.

Perguntas frequentes

O runtime do Azure Functions 1.x ainda é suportado?

Não. O suporte ao runtime do Azure Functions 1.x terminou em 14 de setembro de 2026. Migre os aplicativos afetados para o runtime 4.x para suporte total.

Um modelo de programação Python v1 ou Node.js v4 usa runtime 1.x?

Não. As versões do modelo de programação de linguagem são independentes da versão em tempo de execução. Os modelos de programação Python v1 e v2 e os modelos de programação Node.js v3 e v4 rodam em runtime 4.x.

Recursos relacionados

• Compare versões de runtime do Azure Functions
• Anúncio de suporte ao runtime do Azure Functions 1.x
• Migrar aplicativos do runtime do Azure Functions 1.x para o 4.x