Azure Functions runtime 1.x Legacy reference

Este artículo conserva información histórica clave y enlaza a referencias detalladas de aplicaciones de funciones que aún utilizan el runtime 1.x. No uses runtime 1.x para nuevas aplicaciones de funciones.

Alcance de ejecución 1.x

El runtime de Azure Functions 1.x finalizó el soporte el 14 de septiembre de 2026 y no está compatible con aplicaciones de funciones nuevas o existentes. Runtime 1.x tenía las siguientes características:

• Solo funcionaba en Windows.
• Admitía aplicaciones C# dirigidas a aplicaciones de .NET Framework y JavaScript.
• Las aplicaciones C# se ejecutaban en proceso. Runtime 1.x no soportaba el modelo de trabajador aislado.
• Utilizaba la versión 1.x de Azure Functions Core Tools para el desarrollo local. Core Tools 1.x solo funciona en Windows.
• El tiempo de ejecución incluía sus asignaciones soportadas. Las versiones posteriores de tiempo de ejecución utilizan extensiones de binding versionadas por separado o bundles de extensiones.

Versiones de modelos en tiempo de ejecución, extensión y programación

La versión de Azure Functions en tiempo de ejecución no es la misma que las que usan las extensiones de binding, los paquetes de extensiones o los modelos de programación de lenguaje. Una etiqueta de versión en otro componente no indica que una app use Azure Functions runtime 1.x. Por ejemplo:

• Los modelos de programación en Python v1 y v2 se ejecutan en tiempo de ejecución 4.x.
• Los modelos de programación Node.js v3 y v4 se ejecutan en tiempo de ejecución 4.x.
• Las versiones de paquetes de extensiones y paquetes de binding son independientes de la versión en tiempo de ejecución.

Migrar a tiempo de ejecución 4.x

Para devolver una aplicación al soporte completo, migrásala de runtime 1.x a runtime 4.x. La guía de migración cubre estas tareas:

• Identifica las aplicaciones que apuntan a runtime 1.x.
• Elige un destino compatible con C# o JavaScript.
• Actualiza el proyecto, las acobles, la configuración de la app y host.json archivo.
• Prueba la app localmente y actualiza la app de funciones en Azure.

No cambies solo la configuración de la FUNCTIONS_EXTENSION_VERSION app. Las actualizaciones en tiempo de ejecución pueden requerir cambios en proyectos, código, vinculación y configuración.

Configuración de la app específica para runtime 1.x

La configuración obsoleta AzureWebJobsDashboard solo es compatible con la versión de ejecución 1.x. Contiene una cadena de conexión opcional de cuenta de almacenamiento de propósito general utilizada para almacenar registros y mostrarlos en la pestaña Monitor del portal de Azure.

Runtime 1.x no soporta la AZURE_FUNCTIONS_ENVIRONMENT configuración de la app.

El FUNCTIONS_EXTENSION_VERSION valor ~1 fija una aplicación de función en runtime 1.x. El almacenamiento de claves en el sistema de archivos (AzureWebJobsSecretStorageType=files) es el valor predeterminado.

La functionsRuntimeAdminIsolationEnabled propiedad del sitio no está disponible en runtime 1.x. La FUNCTIONS_V2_COMPATIBILITY_MODE opción no se aplica a las aplicaciones de ejecución 1.x.

Project y diferencias lingüísticas

Los proyectos de librerías de clases C# 1.x en tiempo de ejecución estaban dirigidos a .NET Framework y utilizaban la versión 1.x del Microsoft.NET.Sdk.Functions paquete. Podrían usarse TraceWriter para tala. Para el modelo actual de proyecto C# y consideraciones de migración, consulte la guía para desarrolladores de la biblioteca de clases .NET y la guía de migración en tiempo de ejecución 1.x.

Proyectos de biblioteca de clase C#

El siguiente ejemplo muestra las partes relevantes de un archivo de proyecto 1.x en tiempo de ejecución:

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

Las Microsoft.NET.Sdk.Functions dependencias de paquetes incluyen triggers y bindings. Un proyecto 1.x se refiere a disparadores y enlaces 1.x porque apuntan al Framework .NET. El paquete también depende de Newtonsoft.Json y indirectamente de WindowsAzure.Storage. Estas dependencias aseguran que el proyecto utilice versiones compatibles con el runtime de Funciones objetivo. Por ejemplo, el tiempo de ejecución de Functions que apunta a .NET Framework 4.6.1 es compatible con la 9.0.1, no con Newtonsoft.Json la versión 11.

Runtime 1.x usado TraceWriter para el registro de Application Insights. TraceWriter No soporta registro estructurado.

El siguiente ejemplo crea un TelemetryClient y usa TrackEvent, TrackMetric, y TrackDependency para registrar telemetría personalizada. También utiliza el contexto de ejecución de la función para correlacionar la telemetría personalizada con la invocación actual.

Ejemplo de telemetría 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;
		}
	}
}

Runtime 1.x también soportaba script C# (.csx) y funciones JavaScript. El script C# no es específico de runtime 1.x, así que usa la referencia de desarrollador de scripts C# para orientación general sobre scripts. Utiliza la guía de migración para cambios específicos de tiempo de ejecución.

Para ejemplos de la sintaxis anterior de C#, véase las plantillas de funciones en tiempo de ejecución 1.x.

Ensamblajes y paquetes de scripts C#

En funciones de script 1.x C# en tiempo de ejecución, podrías referenciar los siguientes ensamblajes por un nombre simple:

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

Runtime 1.x utilizaba un archivo project.json para definir dependencias. El siguiente ejemplo añade el Microsoft.ProjectOxford.Face paquete NuGet:

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

Los paquetes de extensiones no son compatibles con runtime 1.x. Para usar un feed NuGet personalizado, especifica el feed en un archivo NuGet.Config en la carpeta raíz de la app función. Para más información, vea Configuring NuGet behavior (Configuración del comportamiento de NuGet).

Desarrollo local con Core Tools 1.x

La versión 1.x de Azure Functions Core Tools está emparejada con runtime 1.x y solo funciona en Windows. Para empezar el runtime, ejecutaste func host start. Para la guía actual sobre desarrollo local, véase Develop Azure Functions locally using Core Tools.

Visual Studio almacenaba las versiones de runtime 1.x de Core Tools y %USERPROFILE%\AppData\Local\Azure.Functions.Cli usaba la última versión almacenada allí. Podías ver la versión seleccionada en la salida de consola al ejecutar el proyecto:

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

Referencia de host.json de ejecución 1.x

El esquemahost.json y los ajustes cambiaron tras la ejecución 1.x. Consulta la referencia de ejecución 1.x host.json al revisar una configuración existente y compárala con la referencia actual de host.json durante la migración.

Monitoriza aplicaciones en tiempo de ejecución 1.x con Application Insights

Runtime 1.x utiliza las siguientes categorías de registros de Application Insights:

Configuración de los niveles de registro

Runtime 1.x configura los niveles de log bajo logger.categoryFilter en host.json:

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

Cuando varios nombres de categorías empiezan con la misma cadena, primero se empareja la categoría más específica. El siguiente ejemplo registra todo excepto Host.Aggregator a nivel Error :

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

Configurar el muestreo

La tasa máxima predeterminada de telemetría es de cinco ítems por segundo. Runtime 1.x configura el muestreo bajo applicationInsights.sampling:

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

El siguiente ejemplo combina filtrado por categorías y muestreo:

{
	"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 no soporta configuración por función.

Capacidades de Application Insights

Runtime 1.x recogía automáticamente solicitudes, excepciones y contadores de rendimiento. No recogía automáticamente dependencias de HTTP, Service Bus, Event Hubs o SQL. Soportaba QuickPulse/Live Metrics sin un canal de control seguro y soportaba muestreo, pero no admitía heartbeats, correlación Service Bus o Event Hubs, ni recogida de telemetría totalmente configurable.

Características y comportamientos no soportados en runtime 1.x

• No se soportan las políticas de reintentos.
• No se soporta la monitorización a escala dinámica de los disparadores de red virtual.
• En los planes Premium y Dedicados, el tiempo de ejecución por defecto de la función es ilimitado. En el plan de Consumo, el tiempo muerto por defecto es de cinco minutos y el máximo de 10 minutos.
• Una aplicación de funciones que utiliza un paquete de despliegue remoto no puede ejecutarse sin un recurso compartido de Azure Files.

Asignaciones incluidas en runtime 1.x

Azure Functions runtime 1.x está retirado. Cuando migres a runtime 4.x, usa extensiones de binding actual o un bundle de extensiones y revisa cada binding para ver si hay cambios de configuración y tipo.

Las siguientes asignaciones se incluyeron en runtime 1.x. La columna de atributo C# muestra los nombres cortos usados en el código. Los nombres de las clases correspondientes tienen un Attribute sufijo, como BlobTriggerAttribute. Las funciones de script C# definen en cambio los bindings en el archivofunction.json .

Las aplicaciones de función que usan runtime 1.x hacen referencia automáticamente al paquete NuGet de Microsoft.Azure. WebJobs NuGet (versión 2.x).

Los disparadores y vinculaciones de Blob Storage, Queue Storage y Table Storage utilizan la versión 7.2.1 del paquete NuGet de WindowsAzure.Storage. Si referencias una versión diferente del SDK de almacenamiento y asignas a un tipo de SDK de almacenamiento en tu firma de función, el runtime de Funciones podría informar que no puede asignarse a ese tipo. Asegúrate de que tu proyecto hace referencia a WindowsAzure.Storage 7.2.1.

Blob Storage bindings en tiempo de ejecución 1.x

Runtime 1.x expuso tipos del espacio de nombres obsoleto de Microsoft. WindowsAzure.Storage. Tipos más recientes de Azure. Storage.Blobs requieren una extensión posterior y un 4.x en tiempo de ejecución.

Vinculaciones de almacenamiento en cola en tiempo de ejecución 1.x

Runtime 1.x expuso tipos del espacio de nombres obsoleto de Microsoft. WindowsAzure.Storage. Tipos más recientes de Azure. Storage.Las colas requieren una extensión posterior y un tiempo de ejecución 4.x.

Para la configuración de vinculación de almacenamiento en colas, consulta la sección de colas de la referencia de ejecución 1.x host.json. En tiempo de ejecución 1.x, la maxPollingInterval configuración se expresa en milisegundos. En versiones posteriores de ejecución, su tipo de dato es TimeSpan.

Enlaces de almacenamiento de tabla en tiempo de ejecución 1.x

Tipos expuestos en tiempo de ejecución 1.x del obsoleto Microsoft. WindowsAzure.Storage.Table. Tipos más recientes de Azure. Data.Tables requieren la extensión y runtime 4.x de Azure Tables.

Ejemplos de entrada

La siguiente función C# lee una sola fila de tabla. Por cada mensaje enviado a la cola, se activa la función. El valor de la clave de fila {queueTrigger} enlaza la clave de la fila a los metadatos del mensaje, que constituyen la cadena de mensaje.

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 siguiente función C# lee varias filas de tabla donde la MyPoco clase 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 la entrada

Para devolver una entidad específica según la clave, use un parámetro de enlace que se derive de TableEntity. Los específicos TableName, PartitionKey, y RowKey se usan para intentar obtener una entidad específica de la tabla.

Para ejecutar consultas que devuelvan varias entidades, establezca un enlace a un objeto IQueryable<T> de un tipo que herede de TableEntity.

Uso de salida

Los tipos que se incluyen a continuación son compatibles con los parámetros out y los tipos de valores devueltos:

• Un objeto CRL estándar (POCO) que incluye las propiedades PartitionKey y RowKey. Puede acompañar a estas propiedades mediante la implementación de ITableEntity o la herencia de TableEntity.
• ICollector<T> o IAsyncCollector<T>, donde T incluye las propiedades PartitionKey y RowKey. Puede acompañar a estas propiedades mediante la implementación de ITableEntity o la herencia de TableEntity.

También puede enlazar desde CloudTableel SDK de Storage como parámetro de método. A continuación, puede usar ese objeto para escribir en la tabla.

Enlaces de Event Hubs en runtime 1.x

Runtime 1.x incluía la vinculación de los Event Hubs y no requería una extensión separada. Expuso el tipo obsoleto de Microsoft.Azure. EventHubs.EventData. Activadores de Event Hubs soportados EventData, tipos JSON-serializables, string, y byte[] para un solo evento, y EventData[] y string[] para un lote. Enlaces de salida soportados EventData, tipos serializables en JSON, string, y byte[].

Para un disparador o enlace de salida de Event Hubs en function.json, runtime 1.x utiliza la path propiedad para el nombre del event hub. Las versiones posteriores en tiempo de ejecución utilizan eventHubName. Cuando el nombre del hub de eventos también está presente en la cadena de conexión, ese valor anula la propiedad en tiempo de ejecución.

El archivo de host.json 1.x en tiempo de ejecución utiliza un objeto de nivel superior eventHub :

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

Para la referencia completa de configuración, véase la eventHub sección de la referencia de host.json 1.x en tiempo de ejecución.

Vinculaciones de la Cuadrilla de Eventos en tiempo de ejecución 1.x

Las versiones de extensiones de Event Grid anteriores a la 3.x no soportan el esquema CloudEvents. Para consumir este esquema, utiliza un trigger HTTP o migra a la ejecución 4.x y la extensión de la Grid de Eventos 3.x.

La vinculación de salida de la Grid de Eventos solo está disponible para tiempo de ejecución 2.x y posteriores.

Tipos de enlaces

La extensión de ejecución 1.x soporta los siguientes tipos de parámetros. No soporta el esquema CloudEvents, que requiere la extensión 3.x de Event Grid.

Uso del desencadenador

Las funciones de la biblioteca de clases C# en proceso soportan los siguientes tipos de disparadores de la Cuadrícula de Eventos:

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

Endpoint y clave del sistema Webhook

El endpoint web alojado para un disparador de Event Grid 1.x en tiempo de ejecución utiliza el siguiente patrón de URL:

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

Para obtener la clave del sistema de la Grid de Eventos de la API de administrador, utilice la clave maestra de la aplicación de funciones en la siguiente petición:

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

Para pruebas locales, el extremo de disparo de la Grid de Eventos utiliza el siguiente patrón de URL:

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

Vinculaciones de Service Bus en tiempo de ejecución 1.x

Runtime 1.x expuso tipos del Microsoft.ServiceBus.Messaging espacio de nombres en WindowsAzure.ServiceBus, que fue retirado para la mensajería de Service Bus el 30 de septiembre de 2026. Migrar a la extensión Service Bus 5.x o posterior y a runtime 4.x para usar Azure. Tipos de Messaging.ServiceBus.

Uso del desencadenador

El disparador de mensajes de cola o tema soporta los siguientes tipos de parámetros:

• BrokeredMessage te da el mensaje deserializado con el método BrokeredMessage.GetBody<T>( ).
• MessageReceiver recibe y acusa recibo de mensajes del contenedor de mensajes. Este tipo es necesario cuando autoComplete se establece en false.

En las bibliotecas de clases C#, el constructor del atributo toma el nombre de la cola o el tema y la suscripción. También puedes especificar los derechos de acceso de la conexión. Si no los especifica, el valor predeterminado es Manage.

Selección de cuentas de Service Bus

Utiliza ServiceBusAccountAttribute para especificar la cuenta de Service Bus. El constructor toma el nombre de una configuración de aplicación que contiene un Service Bus cadena de conexión. Aplica el atributo a nivel de parámetro, método o clase. El siguiente ejemplo muestra atributos a nivel de clase y método:

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

El siguiente orden determina qué cuenta de Service Bus utilizar:

1. La propiedad ServiceBusTrigger del atributo Connection.
2. El atributo ServiceBusAccount aplicado al mismo parámetro que el atributo ServiceBusTrigger.
3. El atributo ServiceBusAccount aplicado a la función.
4. El atributo ServiceBusAccount aplicado a la clase.
5. Configuración de aplicación AzureWebJobsServiceBus.

Metadatos del mensaje

Las siguientes propiedades son miembros de las clases BrokeredMessage y MessageReceiver .

Uso de salida

Use el tipo BrokeredMessage al enviar mensajes con metadatos. Define parámetros como return atributos de tipo. Si el valor del parámetro es nulo cuando la función se cierra, Functions no crea un mensaje.

Para function.json vincula, accessRights acepta manage o listen y se predetermina a manage. Si la cadena de conexión no tiene permiso de Gestionar, configúralo accessRights para listen evitar que el tiempo de ejecución intente operaciones de gestión.

El tiempo de ejecución crea la cola si no existe y configuras accessRights en manage.

Configuración de host

Para Service Bus ajustes de asignación, consulta la referencia de ejecución 1.x host.json.

Enlaces HTTP y webhook en tiempo de ejecución 1.x

Una función activada por HTTP devuelve HTTP 200 OK por defecto con un cuerpo vacío. Las versiones posteriores en tiempo de ejecución devolven HTTP 204 No Content.

Para un disparador HTTP en function.json, utiliza la webHookType propiedad para configurar el disparador y que actúe como receptor webhook para el proveedor especificado. Esta propiedad es específica para el tiempo de ejecución 1.x.

Runtime 1.x no permite acceder a información autenticada del cliente.

Modo webhook

Las plantillas de webhook proporcionan validación adicional para las cargas útiles de webhook. La webHookType propiedad de enlace muestra al proveedor del webhook y controla la carga útil soportada:

Cuando configures webHookType, no configures la methods propiedad.

Para responder a los webhooks de GitHub, crea la función con un trigger HTTP, configúrase webHookType en github, y copie su URL y clave API en la página de Añadir webhook del repositorio de GitHub.

El webhook de Slack genera un token, así que configura una clave específica de función con ese token.

El componente receptor webhook se encarga de la autorización webhook. El mecanismo varía según el tipo de gancho de banda, pero cada mecanismo depende de una llave. Por defecto, se utiliza la tecla de función nombrada default . Para usar otra clave, configura al proveedor del webhook para que envíe el nombre de la clave de una de las siguientes formas:

• En el clientid parámetro de la cadena de consulta, como https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
• En la cabecera de x-functions-clientid la petición.

Para la configuración de binding HTTP, consulta la sección HTTP de la referencia de ejecución 1.x host.json.

Disparador de calentamiento en runtime 1.x

Runtime 1.x no soporta el disparador de calentamiento.

Vinculación de SendGrid en tiempo de ejecución 1.x

Para agregar la extensión al proyecto, instale el paquete NuGet, versión 2.x.

Para la configuración de asignación de SendGrid, consulta la sección SendGrid de la referencia de ejecución 1.x host.json.

Binding de Twilio en tiempo de ejecución 1.x

Agregue la extensión al proyecto instalando el paquete NuGet, versión 1.x.

Para la versión de ejecución 1.x, utiliza las siguientes propiedades de configuración de enlace en el archivofunction.json :

Utiliza la información de vinculación conservada en este artículo solo para entender una aplicación existente. Sigue la guía de migración en tiempo de ejecución y la documentación de enlace actual cuando actualices la app.

Preguntas más frecuentes

¿Sigue soportándose Azure Functions runtime 1.x?

N.º El soporte para Azure Functions runtime 1.x finalizó el 14 de septiembre de 2026. Migra las aplicaciones afectadas a runtime 4.x para soporte completo.

¿Un modelo de programación Python v1 o Node.js v4 usa runtime 1.x?

N.º Las versiones del modelo de programación del lenguaje son independientes de la versión en tiempo de ejecución. Los modelos de programación Python v1 y v2 y los modelos de programación Node.js v3 y v4 funcionan en tiempo de ejecución 4.x.

Recursos relacionados

• Comparar versiones de Azure Functions en tiempo de ejecución
• Anuncio de soporte de Azure Functions runtime 1.x
• Migrar aplicaciones desde el runtime de Azure Functions 1.x a 4.x