Guía para ejecutar Azure Functions en C# en el modelo de trabajo aislado

En este artículo se presenta cómo trabajar con Azure Functions en .NET mediante el modelo de trabajo aislado. Este modelo permite que el proyecto tenga como destino versiones de .NET independientemente de otros componentes en tiempo de ejecución. Para obtener información sobre las versiones específicas de .NET admitidas, consulte versión compatible.

Use los vínculos siguientes para empezar a compilar de inmediato funciones de modelo de trabajo aislado de .NET.

Para más información sobre cómo implementar un proyecto de modelo de trabajo aislado en Azure, consulte Implementación en Azure Functions.

Ventajas del modelo de trabajo aislado

Puede ejecutar las funciones de la biblioteca de clases de .NET en dos modos: en el mismo proceso que el tiempo de ejecución del host de Functions (en proceso) o en un proceso de trabajo aislado. Cuando las funciones de .NET se ejecutan en un proceso de trabajo aislado, puede aprovechar las ventajas siguientes:

• Menos conflictos: dado que las funciones se ejecutan en un proceso independiente, los ensamblados usados en la aplicación no entrarán en conflicto con la versión diferente de los mismos ensamblados que usa el proceso de host.
• Control total del proceso: usted controla la puesta en marcha de la aplicación, lo que significa que puede administrar las configuraciones usadas y el middleware iniciado.
• Inserción de dependencias estándar: dado que tiene control total del proceso, puede usar los comportamientos actuales de .NET para la inserción de dependencias e incorporar middleware a la aplicación de funciones.
• Flexibilidad de versión de .NET: la ejecución fuera del proceso de host significa que las funciones se pueden ejecutar en versiones de .NET no compatibles de forma nativa con el entorno de ejecución de Functions, incluido .NET Framework.

Si tiene una aplicación de funciones de C# existente que se ejecuta en proceso, debe migrar la aplicación para aprovechar estas ventajas. Para más información, consulte Migración de aplicaciones .NET desde el modelo en proceso al modelo de trabajo aislado.

Para ver una comparación exhaustiva entre los dos modelos, consulte Diferencias entre el proceso en proceso y el proceso de trabajo aislado .NET Azure Functions.

Versiones compatibles

Las versiones del entorno de ejecución de Functions admiten versiones específicas de .NET. Para obtener más información sobre las versiones de Functions, consulte Introducción a las versiones de tiempo de ejecución de Azure Functions. La compatibilidad con versiones también depende de si las funciones se ejecutan en proceso o en proceso de trabajo aislado.

En la tabla siguiente, se muestra el nivel más alto de .NET o .NET Framework que se puede usar con una versión específica de Functions.

¹ .NET 6 se admitía anteriormente en ambos modelos, pero alcanzó el fin del soporte técnico oficial el 12 de noviembre de 2024. .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.

² El proceso de compilación también requiere el SDK de .NET.

³ El soporte técnico finaliza para la versión 1.x del runtime de Azure Functions el 14 de septiembre de 2026. Para más información, consulte este anuncio de soporte. Para seguir teniendo soporte completo, debería migrar sus aplicaciones a la versión 4.x.

⁴ El soporte técnico finaliza para el modelo In-Process el 10 de noviembre de 2026. Para más información, consulte este anuncio de soporte. Para seguir teniendo soporte técnico completo, debería migrar sus aplicaciones al modelo de trabajo aislado.

⁵ No se pueden ejecutar aplicaciones de .NET 10 en Linux en el plan de consumo. Para ejecutarse en Linux, en su lugar debe usar el Plan de Consumo flexible.

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.

Estructura del proyecto

Un proyecto de .NET para Azure Functions que usa el modelo de trabajo aislado es básicamente un proyecto de aplicación de consola de .NET destinado a un entorno de ejecución de .NET compatible. Los archivos siguientes son los archivos básicos necesarios en cualquier proyecto aislado de .NET:

• Archivo del proyecto de C# (. csproj) que define el proyecto y las dependencias.
• Archivo program.cs que es el punto de entrada de la aplicación.
• Cualquier archivo de código que defina las funciones.
• Archivo host.json que define la configuración compartida por las funciones de su proyecto.
• Archivo local.settings.json que define las variables de entorno usadas por su proyecto cuando se ejecuta localmente en su máquina.

Para obtener ejemplos completos, vea el proyecto de ejemplo de .NET 8 y el proyecto de ejemplo de .NET Framework 4.8.

Referencias de paquetes

Un proyecto de .NET para Azure Functions que usa el modelo de trabajo aislado usa un conjunto único de paquetes para la funcionalidad principal y las extensiones de enlace.

Paquetes base

Para ejecutar las funciones de .NET en un proceso de trabajo aislado, necesita los siguientes paquetes:

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

Las versiones mínimas de estos paquetes dependen de la versión de .NET de destino:

Versión 2.x

Las versiones 2.x de los paquetes principales cambian los marcos admitidos y proporcionan compatibilidad con las nuevas API de .NET de estas versiones posteriores. Al actualizar a las versiones 2.x, tenga en cuenta los siguientes cambios:

• A partir de la versión 2.0.0 de Microsoft.Azure.Functions.Worker.Sdk:
  • El SDK incluye configuraciones predeterminadas para compilaciones de contenedor delSDK.
  • El SDK incluye compatibilidad con dotnet run cuando se instala la Azure Functions Core Tools. En Windows, instale Core Tools a través de un mecanismo distinto de NPM.
• A partir de la versión 2.0.0 de Microsoft.Azure.Functions.Worker:
  • Esta versión agrega compatibilidad con IHostApplicationBuilder. Algunos ejemplos de esta guía incluyen pestañas para mostrar alternativas mediante IHostApplicationBuilder. Estos ejemplos requieren las versiones 2.x.
  • La validación del ámbito del proveedor de servicios se incluye de forma predeterminada si se ejecuta en un entorno de desarrollo. Este comportamiento coincide con ASP.NET Core.
  • La opción EnableUserCodeException está habilitada de forma predeterminada. La propiedad ahora está marcada como obsoleta.
  • La opción IncludeEmptyEntriesInMessagePayload está habilitada de forma predeterminada. Con esta opción habilitada, las cargas de desencadenador que representan colecciones siempre incluyen entradas vacías. Por ejemplo, si se envía un mensaje sin cuerpo, todavía hay una entrada vacía en string[] para los datos del activador. La inclusión de entradas vacías facilita la referencia cruzada con matrices de metadatos a las que también puede hacer referencia la función. Puede deshabilitar este comportamiento estableciendo IncludeEmptyEntriesInMessagePayload en false en la configuración del servicio de WorkerOptions.
  • La clase ILoggerExtensions cambia su nombre a FunctionsLoggerExtensions. El cambio de nombre impide un error de llamada ambiguo al usar LogMetric() en una instancia de ILogger.
  • En el caso de aplicaciones que usan HttpResponseData, el método WriteAsJsonAsync() ya no establece el código de estado en 200 OK. En 1.x, este comportamiento invalida otros códigos de error que establezca.
• Las versiones 2.x quitan el soporte con TFM de .NET 5.

Paquetes de extensión

Dado que las funciones de proceso de trabajo aislado de .NET usan tipos de enlace diferentes, requieren un conjunto único de paquetes de extensión de enlace.

Encontrará estos paquetes de extensión en Microsoft.Azure.Functions.Worker.Extensions.

Inicio y configuración

Al usar el modelo de trabajo aislado, tiene acceso al inicio de la aplicación de funciones, que normalmente se encuentra en Program.cs. El usuario es responsable de crear e iniciar su propia instancia de host. Como tal, también tiene acceso directo a la canalización de configuración de la aplicación. Con el proceso de trabajo aislado de .NET Functions, puede agregar configuraciones mucho más fácilmente, insertar dependencias y ejecutar su propio middleware.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
        // Log levels can also be configured using appsettings.json. For more information, see https://v4.hkg1.meaqua.org/azure/azure-monitor/app/worker-service#ilogger-logs
        LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

var host = builder.Build();

await host.RunAsync();

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(s =>
    {
        s.AddApplicationInsightsTelemetryWorkerService();
        s.ConfigureFunctionsApplicationInsights();
        s.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
        s.Configure<LoggerFilterOptions>(options =>
        {
            // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
            // Log levels can also be configured using appsettings.json. For more information, see https://v4.hkg1.meaqua.org/en-us/azure/azure-monitor/app/worker-service#ilogger-logs
            LoggerFilterRule? toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");

            if (toRemove is not null)
            {
                options.Rules.Remove(toRemove);
            }
        });
    })
    .Build();

await host.RunAsync();

Configuración

El tipo de generador que usa determina cómo se configura la aplicación.

.ConfigureFunctionsWorkerDefaults()

Estas configuraciones solo se aplican al código de trabajador que desarrolle. No influyen directamente en la configuración del host o los desencadenadores y enlaces de Functions. Para realizar cambios en el host de funciones o el desencadenador y la configuración de enlace, use el archivo host.json.

Inserción de dependencia

El modelo de trabajo aislado usa mecanismos estándar de .NET para insertar servicios.

builder.Services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();

.ConfigureServices(services =>
{
    services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
})

Este código requiere using Microsoft.Extensions.DependencyInjection;. Para obtener más información, consulte Inserción de dependencias en ASP.NET Core.

Registro de clientes de Azure

Use la inserción de dependencias para interactuar con otros servicios de Azure. Puede insertar clientes desde el SDK de Azure para .NET mediante el paquete Microsoft.Extensions.Azure . Después de instalar el paquete, registre los clientes llamando a AddAzureClients() en la colección de servicios de Program.cs. En el ejemplo siguiente se configura un cliente con nombre para Azure Blobs:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(builder.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Azure;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((hostContext, services) =>
    {
        services.AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(hostContext.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });
    })
    .Build();

host.Run();

En el ejemplo siguiente se muestra cómo puede usar este registro y los tipos de SDK para copiar el contenido del blob como una secuencia de un contenedor a otro mediante un cliente insertado:

using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Logging;

namespace MyFunctionApp
{
    public class BlobCopier
    {
        private readonly ILogger<BlobCopier> _logger;
        private readonly BlobContainerClient _copyContainerClient;

        public BlobCopier(ILogger<BlobCopier> logger, IAzureClientFactory<BlobServiceClient> blobClientFactory)
        {
            _logger = logger;
            _copyContainerClient = blobClientFactory.CreateClient("copierOutputBlob").GetBlobContainerClient("samples-workitems-copy");
            _copyContainerClient.CreateIfNotExists();
        }

        [Function("BlobCopier")]
        public async Task Run([BlobTrigger("samples-workitems/{name}", Connection = "MyStorageConnection")] Stream myBlob, string name)
        {
            await _copyContainerClient.UploadBlobAsync(name, myBlob);
            _logger.LogInformation($"Blob {name} copied!");
        }

    }
}

En este ejemplo, ILogger<T> también se obtiene a través de la inserción de dependencias, por lo que se registra automáticamente. Para más información sobre las opciones de configuración para el registro, consulte Registro.

Software intermedio

El modelo de trabajo aislado también admite el registro de middleware, de nuevo mediante un modelo similar al que existe en ASP.NET. Este modelo proporciona la capacidad de insertar lógica en la canalización de invocación, y antes y después de que se ejecuten las funciones.

El método de extensión ConfigureFunctionsWorkerDefaults tiene una sobrecarga que le permite registrar su propio middleware, como se muestra en el ejemplo siguiente.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

// Register our custom middlewares with the worker
builder
    .UseMiddleware<ExceptionHandlingMiddleware>()
    .UseMiddleware<MyCustomMiddleware>()
    .UseWhen<StampHttpHeaderMiddleware>((context) =>
    {
        // We want to use this middleware only for http trigger invocations.
        return context.FunctionDefinition.InputBindings.Values
                        .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
    });

builder.Build().Run();

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(workerApplication =>
    {
        // Register our custom middlewares with the worker

        workerApplication.UseMiddleware<ExceptionHandlingMiddleware>();

        workerApplication.UseMiddleware<MyCustomMiddleware>();

        workerApplication.UseWhen<StampHttpHeaderMiddleware>((context) =>
        {
            // We want to use this middleware only for http trigger invocations.
            return context.FunctionDefinition.InputBindings.Values
                          .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
        });
    })
    .Build();

El UseWhen método de extensión registra un middleware que se ejecuta condicionalmente. Debe pasar un predicado que devuelva un valor booleano a este método. El middleware participa en la canalización de procesamiento de invocación cuando el predicado devuelve true.

Los métodos de extensión siguientes en FunctionContext facilitan el trabajo con el middleware en el modelo aislado.

En este ejemplo se muestra una implementación de middleware que lee la HttpRequestData instancia y actualiza la instancia durante la ejecución de la HttpResponseData función:

internal sealed class StampHttpHeaderMiddleware : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        var requestData = await context.GetHttpRequestDataAsync();

        string correlationId;
        if (requestData!.Headers.TryGetValues("x-correlationId", out var values))
        {
            correlationId = values.First();
        }
        else
        {
            correlationId = Guid.NewGuid().ToString();
        }

        await next(context);

        context.GetHttpResponseData()?.Headers.Add("x-correlationId", correlationId);
    }
}

Este middleware comprueba la presencia de un encabezado de solicitud específico (x-correlationId). Cuando el encabezado está presente, el middleware usa el valor de encabezado para marcar un encabezado de respuesta. De lo contrario, genera un nuevo valor GUID y usa ese valor para marcar el encabezado de respuesta.

Para obtener un ejemplo más completo del uso de middleware personalizado en la aplicación de funciones, consulte el ejemplo de referencia de middleware personalizado.

Personalización de la serialización JSON

El modelo de trabajo aislado usa System.Text.Json de forma predeterminada. Puede personalizar el comportamiento del serializador configurando los servicios como parte del archivo Program.cs. En esta sección se describe la serialización de propósito general y no influye en la serialización JSON del desencadenador HTTP con la integración de ASP.NET Core, que debe configurar por separado.

using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
    {
        jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
        jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
        jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

        // override the default value
        jsonSerializerOptions.PropertyNameCaseInsensitive = false;
    });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
        {
            jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
            jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
            jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

            // override the default value
            jsonSerializerOptions.PropertyNameCaseInsensitive = false;
        });
    })
    .Build();

host.Run();

Para usar JSON.NET (Newtonsoft.Json) para la serialización, instale el Microsoft.Azure.Core.NewtonsoftJson paquete. A continuación, en el registro del servicio, vuelva a asignar la propiedad Serializer en la configuración de WorkerOptions. En el ejemplo siguiente se muestra esta configuración mediante ConfigureFunctionsWebApplication, pero también funciona para ConfigureFunctionsWorkerDefaults:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<WorkerOptions>(workerOptions =>
    {
        var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
        settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
        settings.NullValueHandling = NullValueHandling.Ignore;

        workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
    });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<WorkerOptions>(workerOptions =>
        {
            var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
            settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
            settings.NullValueHandling = NullValueHandling.Ignore;

            workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
        });
    })
    .Build();

host.Run();

Métodos reconocidos como funciones

Un método de función es un método público de una clase pública con un atributo Function aplicado al método y un atributo desencadenador aplicado a un parámetro de entrada, como en el ejemplo siguiente:

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

El atributo desencadenador especifica el tipo de desencadenador y enlaza los datos de entrada a un parámetro del método. La función de ejemplo anterior se desencadena mediante un mensaje de cola y el mensaje de cola se pasa al método en el myQueueItem parámetro .

El atributo Function marca el método como punto de entrada de una función. El nombre debe ser único dentro de un proyecto, empezar con una letra y solo contener letras, números, _y -, hasta 127 caracteres de longitud. Las plantillas de proyecto suelen crear un método denominado Run, pero el nombre de método puede ser cualquier nombre de método de C# válido. Este método debe ser un miembro público de una clase pública. Por lo general, debe ser un método de instancia para que los servicios se puedan pasar a través de la inserción de dependencias.

Parámetros de función

Estos son algunos de los parámetros que puede incluir como parte de una firma de método de función:

• Enlaces, que se marcan como tales mediante la decoración de los parámetros como atributos. La función debe contener exactamente un parámetro de desencadenador.
• Un objeto de contexto de ejecución, que proporciona información sobre la invocación actual.
• Un token de cancelación, que se usa para el apagado ordenado.

Contexto de ejecución

En el modelo de trabajo aislado, el proceso de trabajo pasa un objeto FunctionContext a sus métodos de función. Este objeto permite obtener una instancia de ILogger para escribir en los registros llamando al método GetLogger y proporcionando una cadena categoryName. Puede usar este contexto para obtener un ILogger sin tener que usar la inserción de dependencias. Para obtener más información, vea Registro.

Tokens de cancelación

Una función puede aceptar un parámetro cancellationToken , que permite al sistema operativo notificar al código cuando la función está a punto de terminarse. Puede utilizar esta notificación para asegurarse de que la función no se termina inesperadamente en una forma que deje los datos en un estado incoherente.

Las funciones de .NET que se ejecutan en un proceso de trabajo aislado admiten tokens de cancelación. En el ejemplo siguiente se genera una excepción cuando se recibe una solicitud de cancelación:

[Function(nameof(ThrowOnCancellation))]
public async Task ThrowOnCancellation(
    [EventHubTrigger("sample-workitem-1", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(ThrowOnCancellation));

    foreach (var message in messages)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

En el ejemplo siguiente se realizan acciones de limpieza cuando se recibe una solicitud de cancelación:

[Function(nameof(HandleCancellationCleanup))]
public async Task HandleCancellationCleanup(
    [EventHubTrigger("sample-workitem-2", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(HandleCancellationCleanup));

    foreach (var message in messages)
    {
        if (cancellationToken.IsCancellationRequested)
        {
            _logger.LogInformation("A cancellation token was received, taking precautionary actions.");
            // Take precautions like noting how far along you are with processing the batch
            _logger.LogInformation("Precautionary activities complete.");
            break;
        }

        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

Escenarios que conducen a la cancelación

El token de cancelación se indica cuando se cancela la invocación de función. Varias razones podrían provocar una cancelación y esas razones varían en función del tipo de desencadenador que se use. Estos son algunos de los motivos habituales:

• Desconexión del cliente: el cliente que invoca la función se desconecta. Este motivo es más probable para las funciones de desencadenador HTTP.
• Reinicio de la aplicación de función: usted o la plataforma reinician (o detienen) la aplicación de función aproximadamente al mismo tiempo que se solicita una invocación. Se puede producir un reinicio debido a movimientos de instancias de trabajo, actualizaciones de instancias de trabajo o escalado.

Consideraciones sobre cancelación

• Las invocaciones en curso durante un evento de reinicio se pueden reintentar en función de cómo se desencadenaron. Para obtener más información, consulte la documentación de reintento.

• El host envía la invocación al trabajador incluso si el token de cancelación se cancela antes de que el host pueda enviar la solicitud de invocación al trabajador.

• Si no desea que las invocaciones canceladas previamente se envíen al trabajador, agregue la SendCanceledInvocationsToWorker propiedad al host.json archivo de configuración para deshabilitar este comportamiento.

  En este ejemplo se muestra un host.json archivo que usa esta propiedad:

  {
      "version": "2.0",
      "SendCanceledInvocationsToWorker": "false"
  }
  

• Establecer SendCanceledInvocationsToWorker en false podría provocar una excepción FunctionInvocationCanceled con el siguiente registro:

  Se ha solicitado la cancelación. La solicitud de invocación con el identificador '{invocationId}' se cancela y no será enviada al trabajador.

  Esta excepción se produce cuando se cancela el token de cancelación (como resultado de uno de los eventos descritos anteriormente) antes de que el host envíe una solicitud de invocación entrante al trabajador. Esta excepción se puede omitir de forma segura y se espera cuando SendCanceledInvocationsToWorker es false.

Enlaces

Defina enlaces mediante atributos en métodos, parámetros y tipos de valor devuelto. En su lugar, los enlaces se basan en cadenas, matrices y tipos serializables, como los objetos de clase anterior sin formato (POCO). Para algunas extensiones de enlace, también puede enlazar a tipos específicos de servicio definidos en los SDK de servicio.

Para los desencadenadores HTTP, consulte la sección Desencadenador HTTP.

Para obtener un conjunto completo de ejemplos de referencia que usan desencadenadores y enlaces con funciones de proceso de trabajo aisladas, consulte el ejemplo de referencia de extensiones de enlace.

Enlaces de entrada

Una función puede tener cero o más enlaces de entrada que pasan datos a la función. Al igual que los desencadenadores, se definen los enlaces de entrada aplicando un atributo de enlace a un parámetro de entrada. Cuando se ejecuta la función, el entorno de ejecución intenta obtener los datos especificados en el enlace. Los datos que se solicitan a menudo dependen de la información proporcionada por el desencadenador a través de parámetros de enlace.

Enlaces de salida

Para escribir en un enlace de salida, se debe aplicar un atributo de enlace de salida al método de función. Este atributo define cómo escribir en el servicio enlazado. El valor de retorno del método se escribe en el vinculador de salida. Por ejemplo, en el ejemplo siguiente se escribe un valor de cadena en una cola de mensajes denominada output-queue mediante un enlace de salida:

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
{
    // Use a string array to return more than one message.
    string[] messages = {
        $"Album name = {myQueueItem.Name}",
        $"Album songs = {myQueueItem.Songs}"};

    _logger.LogInformation("{msg1},{msg2}", messages[0], messages[1]);

    // Queue Output messages
    return messages;
}

Varios enlaces de salida

Los datos que se escriben en un enlace de salida siempre son el valor devuelto de la función. Si tiene que escribir en más de un enlace de salida, debe crear un tipo de valor devuelto personalizado. Este tipo de valor devuelto debe tener el atributo de enlace de salida aplicado a una o más propiedades de la clase. El ejemplo siguiente es una función desencadenada por HTTP que usa la integración de ASP.NET Core y escribe tanto en la respuesta HTTP como en un enlace de salida de cola.

public class MultipleOutputBindings
{
    private readonly ILogger<MultipleOutputBindings> _logger;

    public MultipleOutputBindings(ILogger<MultipleOutputBindings> logger)
    {
        _logger = logger;
    }

    [Function("MultipleOutputBindings")]
    public MyOutputType Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
    {
        _logger.LogInformation("C# HTTP trigger function processed a request.");
        var myObject = new MyOutputType
        {
            Result = new OkObjectResult("C# HTTP trigger function processed a request."),
            MessageText = "some output"
        };
        return myObject;
    }

    public class MyOutputType
    {
        [HttpResult]
        public IActionResult Result { get; set; }

        [QueueOutput("myQueue")]
        public string MessageText { get; set; }
    }
}

Al usar tipos de valor devueltos personalizados para varios enlaces de salida con la integración de ASP.NET Core, debe agregar el atributo [HttpResult] a la propiedad que proporciona el resultado. El atributo HttpResult está disponible cuando se usa SDK 1.17.3-preview2 o posterior, junto con versión 3.2.0 o posterior de la extensión HTTP y versión 1.3.0 o posterior de la extensión de ASP.NET Core.

Tipos de SDK

Para algunos tipos de enlace específicos del servicio, puede proporcionar datos de enlace mediante tipos de SDK de servicio y marcos de trabajo. Estos tipos ofrecen funcionalidades adicionales más allá de lo que puede proporcionar una cadena serializada o un objeto CLR sin formato (POCO). Para usar los tipos más recientes, actualice el proyecto para usar versiones más recientes de las dependencias principales.

Al probar los tipos de SDK localmente en la máquina, también deberá usar Azure Functions Core Tools versión 4.0.5000 o posterior. Puede comprobar la versión actual mediante el func --version comando .

Cada extensión de enlace también tiene su propio requisito de versión mínima, que se describe en los artículos de referencia sobre extensiones. Estas extensiones de enlace admiten actualmente tipos de SDK:

Consideraciones para los tipos de SDK:

• Al usar expresiones de enlace que se basan en datos de desencadenador, no se pueden usar tipos de SDK para el propio desencadenador.
• En escenarios de salida en los que puede usar un tipo de SDK, cree y trabaje con clientes del SDK directamente en lugar de usar un enlace de salida.
• El desencadenador de Azure Cosmos DB utiliza el feed de cambios de Azure Cosmos DB y expone los elementos del feed de cambios como tipos serializables JSON. Como resultado, los tipos de SDK no se admiten para este desencadenador.

Desencadenador HTTP

Los desencadenadores HTTP permiten invocar una función mediante una solicitud HTTP. Puede usar dos enfoques diferentes:

• Un modelo de integración de ASP.NET Core que usa conceptos conocidos para desarrolladores de ASP.NET Core
• Un modelo integrado, que no requiere dependencias adicionales y usa tipos personalizados para solicitudes y respuestas HTTP. Este enfoque se mantiene por motivos de compatibilidad con versiones anteriores de aplicaciones de trabajo aisladas de .NET.

Integración de ASP.NET Core

En esta sección se muestra cómo trabajar con los objetos de solicitud y respuesta HTTP subyacentes mediante tipos de ASP.NET Core, incluidos HttpRequest, HttpResponse e IActionResult. Este modelo no está disponible para las aplicaciones destinadas a .NET Framework, que en su lugar deben usar el modelo integrado.

Para habilitar la integración de ASP.NET Core para HTTP:

1. Agregue una referencia en su proyecto al paquete Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore, versión 1.0.0 o posterior.

2. Actualice su proyecto para usar estas versiones específicas de paquetes:

   • Microsoft.Azure.Functions.Worker.Sdk, versión 1.11.0. o posterior
   • Microsoft.Azure.Functions.Worker, versión 1.16.0 o posterior.

3. En el archivo Program.cs, actualice la configuración del generador de hosts para que llame a ConfigureFunctionsWebApplication(). Este método reemplaza ConfigureFunctionsWorkerDefaults() si de lo contrario usarías ese método. En el ejemplo siguiente se muestra una configuración mínima sin otras personalizaciones:

   • IHostBuilder
   • IHostApplicationBuilder

   Nota:

   La aplicación debe hacer referencia a la versión 2.0.0 o posterior de microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore para usar la integración de ASP.NET Core con IHostApplicationBuilder.

   using Microsoft.Azure.Functions.Worker.Builder;
   using Microsoft.Extensions.Hosting;
   
   var builder = FunctionsApplication.CreateBuilder(args);
   
   builder.ConfigureFunctionsWebApplication();    
   
   builder.Build().Run();
   

4. Actualice las funciones existentes desencadenadas por HTTP para usar los tipos de ASP.NET Core. Este ejemplo muestra el HttpRequest estándar y un IActionResult usado para una función sencilla de "hola, mundo":

   [Function("HttpFunction")]
   public IActionResult Run(
       [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
   {
       return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
   }
   

Serialización JSON con integración de ASP.NET Core

ASP.NET Core tiene su propia capa de serialización y no se ve afectada al personalizar la configuración de serialización general. Para personalizar el comportamiento de serialización usado para los desencadenadores HTTP, debe incluir una .AddMvc() llamada como parte del registro del servicio. El devuelto IMvcBuilder se puede usar para modificar la configuración de serialización JSON de ASP.NET Core.

Puede seguir usando HttpRequestData y HttpResponseData mientras usa ASP.NET integración, aunque para la mayoría de las aplicaciones, es mejor usar HttpRequest y IActionResult. El uso HttpRequestData/HttpResponseData de no invoca la capa de serialización de ASP.NET Core y en su lugar, se basa en la configuración general de serialización de trabajo de la aplicación. Sin embargo, cuando se habilita la integración de ASP.NET Core, es posible que tenga que agregar configuración. El comportamiento predeterminado de ASP.NET Core es no permitir la E/S sincrónica. Para usar un serializador personalizado que no admite E/S asincrónica, como NewtonsoftJsonObjectSerializer, debe habilitar la E/S sincrónica para la aplicación mediante la configuración de KestrelServerOptions.

En el ejemplo siguiente se muestra cómo configurar JSON.NET (Newtonsoft.Json) y el paquete NuGet Microsoft.AspNetCore.Mvc.NewtonsoftJson para la serialización mediante este enfoque:

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Services.AddMvc().AddNewtonsoftJson();

// Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
// builder.Services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);

builder.Build().Run();

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
        services.AddMvc().AddNewtonsoftJson();

        // Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
        // services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);
    })
    .Build();
host.Run();

Modelos HTTP integrados

En el modelo integrado, el sistema traduce el mensaje de solicitud HTTP entrante en un objeto HttpRequestData que pasa a la función. Este objeto proporciona datos de la solicitud, incluidos Headers, Cookies, Identities, URL y un mensaje opcional Body. Este objeto representa la solicitud HTTP, pero no está conectada directamente al agente de escucha HTTP subyacente o al mensaje recibido.

Del mismo modo, la función devuelve un objeto HttpReponseData, que proporciona los datos usados para crear la respuesta HTTP, incluido el StatusCode del mensaje, Headers y, opcionalmente, un Body de mensaje.

El siguiente ejemplo muestra el uso de HttpRequestData y HttpResponseData:

[Function(nameof(HttpFunction))]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger(nameof(HttpFunction));
    logger.LogInformation("message logged");

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString("Welcome to .NET isolated worker !!");

    return response;
}

Registro

Puede escribir en los registros mediante una instancia ILogger<T> o ILogger. Puede obtener el registrador a través de la inserción de dependencias de un ILogger<T> o de un ILoggerFactory:

public class MyFunction {
    
    private readonly ILogger<MyFunction> _logger;
    
    public MyFunction(ILogger<MyFunction> logger) {
        _logger = logger;
    }
    
    [Function(nameof(MyFunction))]
    public void Run([BlobTrigger("samples-workitems/{name}", Connection = "")] string myBlob, string name)
    {
        _logger.LogInformation($"C# Blob trigger function Processed blob\n Name: {name} \n Data: {myBlob}");
    }

}

También puedes obtener el registrador de un objeto FunctionContext pasado a tu función. Llame al método GetLogger<T> o GetLogger, y pase un valor de cadena que sea el nombre de la categoría en la que se escriben los registros. La categoría suele ser el nombre de la función específica desde la que se escriben los registros. Para obtener más información sobre las categorías, consulte el artículo de supervisión.

Use los métodos de ILogger<T> y ILogger para escribir varios niveles de registro, como LogWarning o LogError. Para obtener más información sobre los niveles de registro, consulte el artículo de supervisión. Puede personalizar los niveles de registro de los componentes agregados al código registrando filtros:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

// Registers IHttpClientFactory.
// By default this sends a lot of Information-level logs.
builder.Services.AddHttpClient();

// Disable IHttpClientFactory Informational logs.
// Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
builder.Logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    
builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services =>
    {
        // Registers IHttpClientFactory.
        // By default this sends a lot of Information-level logs.
        services.AddHttpClient();
    })
    .ConfigureLogging(logging =>
    {
        // Disable IHttpClientFactory Informational logs.
        // Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
        logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    })
    .Build();

Como parte de la configuración de la aplicación en Program.cs, también puede definir el comportamiento de cómo se muestran los errores en los registros. El comportamiento predeterminado depende del tipo de generador que esté usando.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(builder => {}, options =>
    {
        options.EnableUserCodeException = true;
    })
    .Build();

host.Run();

Application Insights

Puede configurar la aplicación de proceso aislada para enviar registros directamente a Application Insights. Esta configuración reemplaza el comportamiento predeterminado de la retransmisión de registros a través del host. A menos que use Aspire, configure la integración directa de Application Insights porque le proporciona control sobre cómo se emiten esos registros.

La integración de Application Insights no está habilitada de forma predeterminada en todas las experiencias de configuración. Algunas plantillas crean proyectos de Azure Functions con los paquetes necesarios y el código de inicio comentado. Si desea usar la integración de Application Insights, descomente estas líneas en Program.cs y en el archivo de proyecto .csproj. Las instrucciones del resto de esta sección también describen cómo habilitar la integración.

Si tu proyecto forma parte de una orquestación Aspire, utiliza OpenTelemetry para el monitoreo en su lugar. No habilite la integración directa de Application Insights en proyectos aspire. En su lugar, configure el exportador OpenTelemetry de Azure Monitor como parte del proyecto predeterminado del servicio. Si el proyecto de Functions usa la integración de Application Insights en un contexto aspire, la aplicación genera errores al iniciarse.

Instalar paquetes

Para escribir registros directamente en Application Insights desde su código, agregue referencias a estos paquetes en su proyecto:

• Microsoft.Azure.Functions.Worker.ApplicationInsights, versión 1.0.0 o posterior.
• Microsoft.ApplicationInsights.WorkerService.

Ejecute los siguientes comandos para agregar estas referencias al proyecto:

dotnet add package Microsoft.ApplicationInsights.WorkerService
dotnet add package Microsoft.Azure.Functions.Worker.ApplicationInsights

Configuración del inicio

Después de instalar los paquetes, llame a AddApplicationInsightsTelemetryWorkerService() y ConfigureFunctionsApplicationInsights() durante la configuración del servicio en el archivo Program.cs, como se muestra en el ejemplo siguiente.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

La llamada a ConfigureFunctionsApplicationInsights() agrega un ITelemetryModule que escucha a un ActivitySource definido por Functions. En este módulo se crea la telemetría de dependencia necesaria para admitir el seguimiento distribuido. Para obtener más información sobre AddApplicationInsightsTelemetryWorkerService() y cómo usarla, consulte Application Insights para aplicaciones de Worker Service.

Administración de niveles de registro

El resto de la aplicación sigue funcionando con ILogger y ILogger<T>. Pero de manera predeterminada, el SDK de Application Insights agrega un filtro de registro que indica al registrador que capture solo advertencias y registros más graves. Puede configurar los niveles de registro en el proceso de trabajo aislado de una de estas maneras:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .ConfigureLogging(logging =>
    {
        logging.Services.Configure<LoggerFilterOptions>(options =>
        {
            LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (defaultRule is not null)
            {
                options.Rules.Remove(defaultRule);
            }
        });
    })
    .Build();

host.Run();

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.Azure.Functions.Worker": "Information"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureAppConfiguration(config =>
    {
        config.SetBasePath(Directory.GetCurrentDirectory())
              .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
              .AddEnvironmentVariables();
    })
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.Azure.Functions.Worker": "Information"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

Para obtener más información sobre cómo configurar el registro, consulte Registro en .NET y Application Insights para aplicaciones del servicio de trabajo.

Optimizaciones de rendimiento

En esta sección se describen las opciones que puede habilitar para mejorar el rendimiento en torno al arranque de acceso esporádico.

En general, la aplicación debe usar las versiones más recientes de sus dependencias principales. Como mínimo, actualice el proyecto de la siguiente manera:

1. Actualice Microsoft.Azure.Functions.Worker a la versión 1.19.0 o posterior.
2. Actualice Microsoft.Azure.Functions.Worker.Sdk a la versión 1.16.4 o posterior.
3. Agregue una referencia de marco a Microsoft.AspNetCore.App, a menos que la aplicación tenga como destino .NET Framework.

En el fragmento siguiente se muestra esta configuración en el contexto de un archivo del proyecto:

  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
  </ItemGroup>

Marcadores de posición

Los marcadores de posición son una funcionalidad de plataforma que mejora el arranque de acceso esporádico para aplicaciones destinadas a .NET 6 o una versión posterior. Para usar esta optimización, debe habilitar explícitamente los marcadores de posición siguiendo estos pasos:

1. Actualice la configuración del proyecto para usar las versiones de dependencia más recientes, como se detalla en la sección anterior.

2. Establezca la configuración de la WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED aplicación en 1. Use este comando az functionapp config appsettings set:

   az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'
   

   En este ejemplo, sustituya <groupName> por el nombre del grupo de recursos y reemplace <appName> por el nombre de su aplicación de funciones.

3. Asegúrese de que la propiedad netFrameworkVersion de la aplicación de funciones coincide con la plataforma de destino del proyecto, que debe ser .NET 6 o posterior. Use este comando az functionapp config set :

   az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>
   

   En este ejemplo, sustituya también <framework> por la cadena de versión adecuada, como v8.0, según la versión .NET de destino.

4. Asegúrese de que la aplicación de funciones está configurada para usar un proceso de 64 bits. Use este comando az functionapp config set :

   az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false
   

Ejecutor optimizado

El ejecutor de funciones es un componente de la plataforma que hace que se ejecuten invocaciones. Una versión optimizada de este componente está habilitada de forma predeterminada a partir de la versión 1.16.2 del SDK. No es necesario efectuar ninguna otra configuración.

ReadyToRun

La aplicación de funciones se puede compilar como archivos binarios de ReadyToRun. ReadyToRun es una forma de compilación Ahead Of Time que puede mejorar el rendimiento de inicio para ayudar a reducir el impacto del inicio en frío cuando se ejecuta en un plan de consumo. ReadyToRun está disponible en .NET 6 (y versiones posteriores) y requiere la versión 4.0 o posterior del runtime de Azure Functions.

ReadyToRun requiere que compile el proyecto en la arquitectura en tiempo de ejecución de la aplicación de hospedaje. Cuando estas arquitecturas no están alineadas, la aplicación encuentra un error al iniciarse. Seleccione su identificador de tiempo de ejecución en esta tabla:

¹ Solo las aplicaciones de 64 bits son aptas para otras optimizaciones de rendimiento.

Para comprobar si la aplicación de Windows es de 32 o 64 bits, ejecute el siguiente comando de la CLI, sustituyendo <group_name> por el nombre del grupo de recursos y <app_name> por el nombre de la aplicación. Una salida de "true" indica que la aplicación es de 32 bits y "false" indica que es de 64 bits.

 az functionapp config show -g <group_name> -n <app_name> --query "use32BitWorkerProcess"

Puede cambiar la aplicación a 64 bits con el siguiente comando mediante las mismas sustituciones:

az functionapp config set -g <group_name> -n <app_name> --use-32bit-worker-process false`

Para compilar un proyecto como ReadyToRun, actualice el archivo del proyecto agregando los elementos <PublishReadyToRun> y <RuntimeIdentifier>. El ejemplo siguiente muestra una configuración para publicar en una aplicación de funciones de Windows de 64 bits.

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

Si no desea establecer el <RuntimeIdentifier> como parte del archivo del proyecto, también puede configurar esta opción como parte del propio proceso de publicación. Por ejemplo, con una aplicación de funciones de Windows de 64 bits, el comando de la CLI de .NET es:

dotnet publish --runtime win-x64

En Visual Studio, establezca la opción Tiempo de ejecución de destino en el perfil de publicación del identificador de tiempo de ejecución correcto. Cuando se establece en el valor predeterminado de Portable, no se usa ReadyToRun.

Implementación en Azure Functions

Al implementar el proyecto de código de función en Azure, debe ejecutarse en una aplicación de funciones o en un contenedor de Linux. Debe crear la aplicación de funciones y otros recursos de Azure necesarios antes de implementar el código.

También puede implementar la aplicación de funciones en un contenedor de Linux. Para obtener más información, consulte Trabajar con contenedores y Azure Functions.

Creación de recursos de Azure

Puede crear la aplicación de funciones y otros recursos necesarios en Azure mediante uno de estos métodos:

• Visual Studio: Visual Studio puede crear recursos automáticamente durante el proceso de publicación de código.
• Visual Studio Code: Visual Studio Code puede conectarse a la suscripción, crear los recursos necesarios para la aplicación y, a continuación, publicar el código.
• CLI de Azure: use la CLI de Azure para crear los recursos necesarios en Azure.
• Azure PowerShell: use Azure PowerShell para crear los recursos necesarios en Azure.
• Plantillas de implementación: use plantillas de ARM y archivos de Bicep para automatizar la implementación de los recursos necesarios en Azure. Asegúrese de que su plantilla incluye cualquier configuración necesaria.
• Azure Portal: cree los recursos necesarios en Azure Portal.

Publicación de la aplicación

Después de crear la aplicación de funciones y otros recursos necesarios en Azure, implemente el proyecto de código en Azure mediante uno de estos métodos:

• Visual Studio: implementación manual sencilla durante el desarrollo.
• Visual Studio Code: implementación manual sencilla durante el desarrollo.
• Azure Functions Core Tools: implemente el archivo de proyecto desde la línea de comandos.
• Implementación continua: útil para el mantenimiento continuo, con frecuencia en un espacio de ensayo.
• Plantillas de implementación: Puede usar plantillas ARM o archivos Bicep para automatizar la implementación de paquetes.

Para más información, vea Tecnologías de implementación en Azure Functions.

Carga de implementación

Muchos de los métodos de implementación usan un archivo ZIP. Si crea el archivo ZIP usted mismo, debe seguir la estructura que se describe en esta sección. Si no es así, la aplicación podría experimentar errores al iniciarse.

La carga de implementación debe coincidir con la salida de un comando dotnet publish, aunque sin la carpeta principal envolvente. El archivo ZIP debe realizarse a partir de los siguientes archivos:

• .azurefunctions/
• extensions.json
• functions.metadata
• host.json
• worker.config.json
• Ejecutable del proyecto (una aplicación de consola)
• Otros archivos auxiliares y directorios del mismo nivel a ese ejecutable

El proceso de compilación genera estos archivos y no debe editarlos directamente.

Al preparar un archivo ZIP para la implementación, comprima solo el contenido del directorio de salida, no el propio directorio envolvente. Cuando el archivo se extrae en el directorio de trabajo actual, los archivos enumerados anteriormente deben estar visibles inmediatamente.

Requisitos de implementación

Para ejecutar funciones de .NET en el modelo de trabajo aislado en Azure, debe cumplir algunos requisitos. Los requisitos dependen del sistema operativo:

Al crear la aplicación de funciones en Azure mediante los métodos de la sección anterior, esta configuración necesaria se agrega automáticamente. Cuando cree estos recursos utilizando plantillas ARM o archivos Bicep para la automatización, debe asegurarse de establecerlos en la plantilla.

Aspirar

Aspire es una pila con opiniones que simplifica el desarrollo de aplicaciones distribuidas en la nube. Puede inscribir proyectos de modelo de trabajo aislados en orquestaciones Aspire 13. Consulte Azure Functions con Aspire para más información.

Depuración

Cuando se ejecuta localmente mediante Visual Studio o Visual Studio Code, puede depurar el proyecto de trabajo aislado de .NET de la manera normal. Sin embargo, hay dos escenarios de depuración que no funcionan según lo previsto.

Depuración remota con Visual Studio

Dado que la aplicación de proceso de trabajo aislado se ejecuta fuera del entorno de ejecución de Functions, debe asociar el depurador remoto a un proceso independiente. Para obtener más información sobre la depuración mediante Visual Studio, consulte Depuración remota.

Depuración al utilizar .NET Framework como destino

Si el proyecto aislado tiene como destino .NET Framework 4.8, debe realizar pasos manuales para habilitar la depuración. Estos pasos no son necesarios si se usa otra plataforma de destino.

La aplicación debe empezar con una llamada a FunctionsDebugger.Enable(); como primera operación. Esto ocurre en el método Main() antes de inicializar un HostBuilder. El archivo Program.cs debe tener un aspecto similar al siguiente:

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

namespace MyDotnetFrameworkProject
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = FunctionsApplication
                .CreateBuilder(args)
                .Build();

            host.Run();
        }
    }
}

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

namespace MyDotnetFrameworkProject
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .Build();

            host.Run();
        }
    }
}

A continuación, debe asociarse manualmente al proceso mediante un depurador de .NET Framework. Visual Studio no hace esto automáticamente para aplicaciones de .NET Framework de proceso de trabajo aislado y se debe evitar la operación "Iniciar depuración".

En el directorio del proyecto (o su directorio de salida de compilación), ejecute:

func host start --dotnet-isolated-debug

Esto inicia el trabajo y el proceso se detiene con el siguiente mensaje:

Azure Functions .NET Worker (PID: <process id>) initialized in debug mode. Waiting for debugger to attach...

Donde <process id> es el id. del proceso de trabajo. Ahora puede usar Visual Studio para asociarse manualmente al proceso. Para instrucciones sobre esta operación, consulte Asociación con un proceso en ejecución.

Una vez asociado el depurador, la ejecución del proceso se reanuda y podrá depurar.

Versiones preliminares de .NET

Antes de una versión disponible con carácter general, es posible que una versión de .NET se publique en el estado Versión preliminar o Publicación. Consulte la directiva de soporte técnico oficial de .NET para obtener más información sobre estos estados.

Aunque puede tener como destino una versión determinada de un proyecto local de Functions, es posible que las aplicaciones de función hospedadas en Azure no tengan esa versión disponible. Azure Functions solo se puede usar con las versiones Versión preliminar o Publicación que se indican en esta sección.

Azure Functions no funciona actualmente con ninguna versión de .NET "Preview" o "Go-live". Consulte Versiones admitidas para obtener una lista de versiones disponibles con carácter general que puede usar.

Uso de un SDK de .NET en versión preliminar

Para usar Azure Functions con una versión preliminar de .NET, debe actualizar el proyecto mediante lo siguiente:

1. Instalación de la versión pertinente del SDK de .NET en desarrollo
2. Cambiando la configuración TargetFrameworken el archivo .csproj

Al implementar en una aplicación de funciones en Azure, también debe asegurarse de que el marco está disponible para la aplicación. Durante el período de versión preliminar, es posible que algunas herramientas y experiencias no muestren la nueva versión preliminar como opción. Si no ve la versión preliminar incluida en Azure Portal, por ejemplo, puede usar la API REST, los archivos de Bicep o la CLI de Azure para configurar la versión manualmente.

az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

az functionapp config set -g <groupName> -n <appName> --linux-fx-version "dotnet-isolated|<version>"

Consideraciones sobre el uso de versiones preliminares de .NET

Tenga en cuenta estas consideraciones al usar Functions con versiones preliminares de .NET:

• Al crear las funciones en Visual Studio, debe usar Visual Studio Insiders, que admite la creación de proyectos de Azure Functions con SDK de versión preliminar de .NET.

• Asegúrese de que tiene las últimas herramientas y plantillas de Functions. Para actualizar las herramientas:

  1. Vaya a Opciones de herramientas>, elija Azure Functions en Proyectos y soluciones>.
  2. Seleccione Buscar actualizaciones e instale las actualizaciones según se le solicite.

• Durante el período de versión preliminar, el entorno de desarrollo podría tener una versión más reciente de la versión preliminar de .NET que el servicio hospedado. Esto puede hacer que se produzca un error en la aplicación de funciones cuando se implementa. Para solucionar esto, puede especificar la versión del SDK que se va a usar en global.json.

  1. Ejecute el comando dotnet --list-sdks y anote la versión preliminar que está usando actualmente durante el desarrollo local.
  2. Ejecute el comando dotnet new globaljson --sdk-version <SDK_VERSION> --force, donde <SDK_VERSION> es la versión que usa localmente. Por ejemplo, dotnet new globaljson --sdk-version dotnet-sdk-10.0.100-preview.5.25277.114 --force hace que el sistema use el SDK de .NET 10 Preview 5 al compilar el proyecto.

Pasos siguientes