Comparteix a través de

Introducción a las versiones de tiempo de ejecución de Azure Functions

  • Article

Actualmente, Azure Functions admite dos versiones del host en tiempo de ejecución. En la tabla siguiente se detallan las versiones del entorno de ejecución admitidas actualmente, su nivel de soporte y cuándo se deben usar:

Versión Nivel de compatibilidad Descripción
4.x GA Versión recomendada en tiempo de ejecución para funciones en todos los lenguajes. Consulte Versiones de lenguajes compatibles.
1.x Disponibilidad general (el soporte técnico finaliza el 14 de septiembre de 2026) Solo se admite para aplicaciones de C# que deben usar .NET Framework. Esta versión está en modo de mantenimiento y solo se realizarán mejoras en versiones posteriores. El soporte técnico para la versión 1.x finalizará el 14 de septiembre de 2026. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x, que admite .NET Framework 4.8, .NET 6, .NET 8 y .NET 9.

Importante

Desde el 13 de diciembre de 2022, las aplicaciones de funciones que se ejecutan en las versiones 2.x y 3.x del entorno de ejecución de Azure Functions han alcanzado el final del soporte extendido. Para más información, vea Versiones retiradas.

En este artículo se detallan algunas de las diferencias entre las versiones admitidas, cómo se puede crear cada versión y cómo cambiar la versión en la que se ejecutan las funciones.

Niveles de soporte

Hay dos niveles de compatibilidad:

  • Disponibilidad general (GA) : totalmente compatible y aprobado para su uso en producción.
  • Versión preliminar: todavía no se admite, pero se espera que llegue al estado de disponibilidad general en el futuro.

Lenguajes

Todas las funciones de una aplicación de función deben compartir el mismo lenguaje. Al crear la aplicación de funciones elige el lenguaje de las funciones. El lenguaje de la aplicación de funciones se mantiene en la configuración FUNCTIONS_WORKER_RUNTIME y no se puede cambiar cuando hay funciones existentes.

En la tabla siguiente se muestran las versiones de .NET compatibles con Azure Functions. Seleccione el lenguaje de desarrollo que prefiera en la parte superior de este artículo.

La versión admitida de .NET depende de la versión en tiempo de ejecución de Functions y del modelo de ejecución elegido:

El código de función se ejecuta en un proceso de trabajo de .NET independiente. Se usa con versiones compatibles de .NET y .NET Framework. Para obtener más información, consulte Desarrollo de funciones de procesos de trabajo aislados en .NET.

Versión admitida Nivel de compatibilidad Fecha esperada de EOL de la comunidad
.NET 9 Vista previa Consulte la directiva
.NET 8 GA 10 de noviembre de 2026
.NET 6 GA 12 de noviembre de 2024
.NET Framework 4.8.1 GA Consulte la directiva

.NET 7 se admitía anteriormente en el modelo de trabajo aislado, pero llegó al final del soporte técnico oficial el 14 de mayo de 2024.

Para más información, consulte Guía para ejecutar funciones de Azure Functions desarrolladas con C# en un proceso de trabajo aislado.

En la tabla siguiente se muestran las versiones del lenguaje compatibles con las funciones de Java. Seleccione el lenguaje de desarrollo que prefiera en la parte superior de este artículo.

Versión admitida Nivel de compatibilidad Fecha esperada de EOL de la comunidad
Java 21 (solo Linux) Vista previa Septiembre de 2028
Java 17 GA Septiembre de 2027
Java 11 GA Septiembre de 2027
Java 8 GA 30 de noviembre de 2026

Para más información, vea la Guía de Azure Functions para desarrolladores de Java.

En la tabla siguiente se muestran las versiones del lenguaje compatibles con las funciones de Node.js. Seleccione el lenguaje de desarrollo que prefiera en la parte superior de este artículo.

Versión admitida Nivel de compatibilidad Fecha esperada de EOL de la comunidad
Node.js 22 Vista previa 30 de abril de 2027
Node.js 20 GA 30 de abril de 2026
Node.js 18 GA 30 de abril de 2025

TypeScript se admite mediante la transpilación a JavaScript. Para más información, vea la Guía de Azure Functions para desarrolladores de Node.js.

En la tabla siguiente se muestran las versiones del lenguaje compatibles con las funciones de PowerShell. Seleccione el lenguaje de desarrollo que prefiera en la parte superior de este artículo.

Versión admitida Nivel de compatibilidad Fecha esperada de EOL de la comunidad
PowerShell 7.4 GA 10 de noviembre de 2026
PowerShell 7.2 GA 8 de noviembre de 2024

Para más información, consulte Guía del desarrollador de PowerShell para Azure Functions.

En la tabla siguiente se muestran las versiones del lenguaje compatibles con las funciones de Python. Seleccione el lenguaje de desarrollo que prefiera en la parte superior de este artículo.

Versión admitida Nivel de compatibilidad Fecha esperada de EOL de la comunidad
Python 3.11 GA Octubre de 2027
Python 3.10 GA Octubre de 2026
Python 3.9 GA Octubre de 2025
Python 3.8 GA Octubre de 2024

Para más información, consulte Guía de Azure Functions para desarrolladores de Python.

Para información sobre los cambios planeados en la compatibilidad de lenguaje, consulte Azure roadmap.

Para obtener información sobre las versiones de lenguaje de las versiones admitidas anteriormente del entorno de ejecución de Functions, vea Versiones del entorno de ejecución retiradas.

Ejecución en una versión específica

La versión del sistema en ejecución de Functions que usan las aplicaciones publicadas en Azure viene determinada por la configuración de la aplicación FUNCTIONS_EXTENSION_VERSION. En algunos casos y para determinados idiomas, se puede aplicar otra configuración.

De forma predeterminada, las aplicaciones de funciones que se crean en Azure Portal, con la CLI de Azure o desde las herramientas de Visual Studio se establecen en la versión 4.x. Puede modificar esta versión en caso necesario. Solo puede degradar la versión del entorno en tiempo de ejecución a 1.x después de crear la aplicación de funciones, pero antes de agregar ninguna función. La actualización a una versión principal posterior se permite incluso con las aplicaciones que tienen funciones existentes.

Migración de las aplicaciones de funciones existentes

Cuando la aplicación tenga funciones existentes, deberá tomar precauciones antes de pasar a una versión posterior del runtime principal. En los artículos siguientes se detallan los cambios importantes entre las versiones principales, incluidos los cambios importantes específicos del lenguaje. También se proporcionan instrucciones paso a paso para una migración correcta de la aplicación de funciones existente.

Cambio de la versión de las aplicaciones en Azure

Se usan los siguientes valores principales de la versión del runtime:

Value Destino del entorno en tiempo de ejecución
~4 4.x
~1 1.x

Importante

No cambie este valor de la aplicación sin motivo, ya que se podrían necesitar otros cambios de valor de aplicación y cambios en el código de función. Para las aplicaciones de funciones existentes, siga las instrucciones de migración.

Anclaje a una versión secundaria específica

Para resolver problemas que pueda tener la aplicación de funciones al ejecutarse en la versión principal más reciente, tiene que anclar temporalmente la aplicación a una versión secundaria determinada. El anclaje le proporciona tiempo para que la aplicación se ejecute correctamente en la versión principal más reciente. La forma de anclar a una versión secundaria difiere entre Windows y Linux. Para más información, consulte Cómo seleccionar un destino para versiones en tiempo de ejecución de Azure Functions.

Las versiones secundarias anteriores se quitan periódicamente de Functions. Para obtener las últimas noticias sobre las versiones de Azure Functions, incluida la eliminación de versiones secundarias específicas anteriores, revise los anuncios de Azure App Service.

Versiones de extensión mínimas

Técnicamente no hay correlación entre las versiones de extensión de enlace y la versión del entorno de ejecución de Functions. Pero a partir de la versión 4.x, el entorno de ejecución de Functions aplica una versión mínima para todas las extensiones de desencadenador y enlace.

Si recibe una advertencia sobre un paquete que no cumple una versión mínima necesaria, debe actualizar ese paquete NuGet a la versión mínima como lo haría normalmente. Los requisitos mínimos de versión de las extensiones usadas en Functions v4.x se pueden encontrar en el archivo de configuración vinculado.

En el caso del script de C#, actualice la referencia del conjunto de extensiones en host.json de la siguiente manera:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

Técnicamente no hay correlación entre las versiones del conjunto de extensiones y la versión del entorno de ejecución de Functions. Pero a partir de la versión 4.x, el entorno de ejecución de Functions aplica una versión mínima para los conjuntos de extensiones.

Si recibe una advertencia sobre una versión del conjunto de extensiones que no cumple una versión mínima necesaria, actualice la referencia del conjunto de extensiones existente en host.json de la siguiente manera:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

Para más información sobre los conjuntos de extensiones, vea Conjuntos de extensiones.

Versiones retiradas

Importante

La compatibilidad con la versión 1.x del entorno de ejecución de Azure Functions finalizará el 14 de septiembre de 2026. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x para obtener soporte completo.

Estas versiones del entorno de ejecución de Functions llegaron al final del soporte extendido el 13 de diciembre de 2022.

Versión Nivel de soporte técnico actual Nivel de soporte técnico anterior
3.x Sin soporte técnico GA
2.x Sin soporte técnico GA

Tan pronto como sea posible, debe migrar las aplicaciones a la versión 4.x para obtener soporte técnico completo. Para obtener un conjunto completo de instrucciones de migración específicas del lenguaje,vea Migración de aplicaciones a Azure Functions versión 4.x.

Las aplicaciones que utilizan las versiones 2.x y 3.x pueden seguir creándose y desplegándose desde su canal CI/CD DevOps, y todas las aplicaciones existentes siguen ejecutándose sin cambios de última hora. Pero las aplicaciones no son aptas para recibir nuevas características, revisiones de seguridad ni optimizaciones del rendimiento. Solo puede obtener soporte técnico del servicio relacionado después de actualizar las aplicaciones a la versión 4.x.

El fin del soporte técnico para las versiones 2.x y 3.x se debe al fin del soporte técnico con .NET Core 3.1, que tenían como dependencia principal. Este requisito afecta a todos los lenguajes admitidos por Azure Functions.

Versiones de aplicaciones desarrolladas de forma local

Puede hacer que las siguientes actualizaciones de las aplicaciones de funciones cambien localmente las versiones de destino.

Versiones de Runtime en Visual Studio

En Visual Studio se selecciona la versión del entorno de ejecución al crear un proyecto. Las herramientas de Azure Functions para Visual Studio son compatibles con las dos versiones principales del entorno de ejecución. Se usa la versión correcta al depurar y publicar en función de configuración del proyecto. La configuración de la versión se define en el archivo .csproj en las siguientes propiedades:

<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

Si usa el modelo de trabajo aislado, puede elegir, net8.0, net6.0, o net48 como marco de destino. También puede usar compatibilidad con la versión preliminar para net9.0. Si usa la modelo en proceso, puede elegir net8.0 o net6.0, y debe incluir la extensión Microsoft.NET.Sdk.Functions establecida en al menos 4.4.0.

.NET 7 se admitía anteriormente en el modelo de trabajo aislado, pero llegó al final del soporte técnico oficial el 14 de mayo de 2024.

Visual Studio Code y Azure Functions Core Tools

Azure Functions Core Tools se usa para el desarrollo de la línea de comandos, pero también lo usa la extensión de Azure Functions para Visual Studio Code. Para más información, consulte Instalación de Azure Functions Core Tools.

Para el desarrollo en Visual Studio Code, es posible que también tenga que actualizar la configuración de usuario en azureFunctions.projectRuntime para que coincida con la versión de las herramientas instaladas. Esta configuración también actualiza las plantillas y los lenguajes utilizados durante la creación de la aplicación de función.

Enlaces

A partir de la versión 2.x, el entorno de ejecución usa un nuevo modelo de extensibilidad de enlaces que ofrece estas ventajas:

  • Compatibilidad con extensiones de enlace de terceros.

  • Desacoplamiento de tiempo de ejecución y enlaces. Este cambio permite el control de versiones y la publicación de las extensiones de enlace de forma independiente. Por ejemplo, puede elegir actualizar a una versión de una extensión que se basa en una versión más reciente de un SDK subyacente.

  • Un entorno de ejecución más ligero, donde solo se conocen y se cargan en tiempo de ejecución los enlaces que están en uso.

A excepción de los desencadenadores HTTP y de temporizador, todos los enlaces deben agregarse explícitamente al proyecto de aplicación de funciones o registrarse en el portal. Para más información, consulte Registro de extensiones de enlace.

En la siguiente tabla se indica qué enlaces se admiten en cada versión del entorno de ejecución.

En esta tabla se muestran los enlaces que son compatibles con las versiones principales del entorno en tiempo de ejecución de Azure Functions:

Tipo 1.x1 2.x y versiones posteriores2 Desencadenador Entrada Output
Blob Storage ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Azure Data Explorer ✔ ✔ ✔
SQL de Azure ✔ ✔ ✔ ✔
Dapr4 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
HTTP y webhooks ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka3 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Centros de notificaciones ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
Redis ✔ ✔
RabbitMQ3 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Table storage ✔ ✔ ✔ ✔
Temporizador ✔ ✔ ✔
Twilio ✔ ✔ ✔

Notas:

  1. La compatibilidad con la versión 1.x del entorno de ejecución de Azure Functions finalizará el 14 de septiembre de 2026. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x para obtener soporte completo.
  2. A partir del entorno de ejecución de la versión 2.x, se deben registrar todos los enlaces excepto HTTP y Timer. Consulte Registro de extensiones de enlace.
  3. Los desencadenadores no se admiten en el plan de consumo. Requiere desencadenadores controlados por el runtime.
  4. Solo se admite en Kubernetes, IoT Edge y otros modos autohospedados.

Duración del tiempo de espera de una aplicación de función

La duración del tiempo de espera de las funciones en una aplicación de funciones se define mediante la propiedad functionTimeout en el archivo de proyecto host.json. Esta propiedad se aplica específicamente a las ejecuciones de funciones. Una vez que el desencadenador inicia la ejecución de la función, la función debe devolver o responder dentro de la duración del tiempo de espera. Para evitar tiempos de espera, es importante escribir funciones sólidas. Para más información, consulte Mejorar el rendimiento y la confiabilidad de Azure Functions.

En la tabla siguiente se muestran los valores predeterminados y máximos (en minutos) para planes específicos:

Plan Valor predeterminado Máximo 1
Plan de consumo flexible 30 Sin enlazar2
Plan Premium 304 Sin enlazar2
Plan dedicado 304 Sin enlazar3
Aplicaciones de contenedor 30 Sin enlazar5
Plan de consumo 5 10
  1. Independientemente de la configuración del tiempo de espera de la aplicación de función, 230 segundos es la cantidad de tiempo máxima que una función desencadenada por HTTP puede tardar en responder a una solicitud. Esto se debe al tiempo de espera de inactividad predeterminado de Azure Load Balancer. Para tiempos de procesamiento más largos, considere la posibilidad de usar el patrón asincrónico de Durable Functions o aplazar el trabajo real y devolver una respuesta inmediata.
  2. No se impone una duración máxima del tiempo de espera de ejecución. Sin embargo, el período de gracia proporcionado a una ejecución de una función es de 60 minutos durante la reducción horizontal para los planes Flex Consumption y Premium, y se da un período de gracia de 10 minutos durante las actualizaciones de la plataforma.
  3. Requiere que el plan de App Service se establezca en Always On. Se da un período de gracia de 10 minutos durante las actualizaciones de la plataforma.
  4. El tiempo de espera predeterminado para la versión 1.x del entorno de ejecución del host de Functions es ilimitado.
  5. Cuando el número mínimo de réplicas se establece en cero, el tiempo de espera predeterminado depende de los desencadenadores específicos usados en la aplicación.

Pasos siguientes

Para obtener más información, consulte los siguientes recursos: