Compartir a través de

Migración de aplicaciones de C# desde el modelo en proceso al modelo de trabajo aislado

Importante

La compatibilidad con el modelo en proceso finaliza el 10 de noviembre de 2026. Le recomendamos encarecidamente que migre las aplicaciones al modelo de trabajo aislado siguiendo las instrucciones de este artículo.

En este artículo se explica el proceso de migración segura de la aplicación de funciones de .NET desde el modelo en proceso al modelo de trabajo aislado. Para obtener información sobre las diferencias de alto nivel entre estos modelos, consulte la comparación de modos de ejecución.

En esta guía se supone que la aplicación se ejecuta en la versión 4.x del entorno de ejecución de Functions. Si no es así, debe usar las siguientes guías para actualizar su versión de host. Estas guías de migración de versiones de host también le ayudan a migrar al modelo de trabajo aislado mientras trabaja a través de ellas.

Cuando se admite, en este artículo se aprovecha la integración de ASP.NET Core en el modelo de trabajo aislado, lo que mejora el rendimiento y proporciona un modelo de programación familiar cuando la aplicación usa desencadenadores HTTP.

Identificación de las aplicaciones de funciones que se deben migrar

Use el siguiente script de Azure PowerShell para generar una lista de aplicaciones de funciones en la suscripción que actualmente usan el modelo en proceso.

El script usa la suscripción para la cual Azure PowerShell está configurado actualmente. Puede cambiar la suscripción ejecutando Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' primero y reemplazando <YOUR SUBSCRIPTION ID> por el identificador de la suscripción que quiere evaluar.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

Elección de la versión .NET de destino

En la versión 4.x del entorno de ejecución de Functions, la aplicación de funciones de .NET tiene como destino .NET 6 o .NET 8 cuando se usa el modelo en proceso.

Al migrar la aplicación de funciones, tiene la oportunidad de elegir la versión de destino de .NET. Puede actualizar el proyecto de C# a una de las siguientes versiones de .NET compatibles con la versión 4.x de Functions:

Versión de .NET Tipo de versión de directiva de soporte técnico oficial de .NET Modelo de proceso de funciones1,2
.NET 9 STS (finalización del soporte técnico 12 de mayo de 2026) Modelo de trabajo aislado
.NET 8 LTS (final del soporte técnico 10 de noviembre de 2026) Modelo de trabajo aislado,
Modelo In-Process2
.NET Framework 4.8 Consulte la directiva Modelo de trabajo aislado

1 El modelo de trabajo aislado admite las versiones de Soporte técnico a largo plazo (LTS) y Soporte técnico de términos estándar (STS) (STS) de .NET, así como .NET Framework. El modelo In-Process solo admite versiones LTS de .NET, que terminan con .NET 8. Para obtener una comparación completa de características y funcionalidades entre los dos modelos, consulte Diferencias entre el proceso en proceso y el proceso de trabajador aislado .NET Azure Functions.

2 El soporte técnico finaliza para el modelo en proceso el 10 de noviembre de 2026. Para más información, consulte este anuncio de soporte. Para seguir disfrutando de soporte técnico completo, debería migrar sus aplicaciones al modelo de trabajador aislado.

Sugerencia

Se recomienda actualizar a .NET 8 en el modelo de trabajo aislado. Esto proporciona una ruta de migración rápida a la versión completamente publicada con la ventana de soporte técnico más larga de .NET.

Esta guía no presenta ejemplos específicos para .NET 9. Si necesita tener como destino esta versión, puede adaptar los ejemplos de .NET 8.

Preparación para la migración

Antes de migrar una aplicación al modelo de trabajo aislado, debe revisar exhaustivamente el contenido de esta guía. También debe familiarizarse con las características del modelo de trabajo aislado y las diferencias entre los dos modelos.

Para migrar la aplicación:

  1. Migre el proyecto local al modelo de trabajo aislado siguiendo los pasos descritos en Migración del proyecto local.
  2. Tras migrar el proyecto, pruebe completamente la aplicación localmente con la versión 4.x de Azure Functions Core Tools.
  3. Actualice la aplicación de funciones en Azure al modelo aislado.

Migración del proyecto local

La sección describe los distintos cambios que debe realizar en el proyecto local para moverlos al modelo de trabajo aislado. Algunos de los pasos cambian en función de la versión de destino de .NET. Use las pestañas para seleccionar las instrucciones que coincidan con la versión deseada.

Sugerencia

Si va a pasar a una versión LTS o STS de .NET, se puede usar el Asistente para actualización de .NET para realizar automáticamente muchos de los cambios mencionados en las secciones siguientes.

En primer lugar, convierta el archivo del proyecto y actualice las dependencias. Al hacerlo, verá errores de desarrollo del proyecto. En los pasos posteriores, realizará los cambios correspondientes para quitar estos errores.

Archivo del proyecto

El ejemplo siguiente es un archivo de proyecto .csproj que usa .NET 8 en la versión 4.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Use uno de los procedimientos siguientes para actualizar este archivo XML para que se ejecute en el modelo de trabajo aislado:

En estos pasos suponen un proyecto de C# local. Si, en su lugar, la aplicación usa el script de C# (archivos .csx), debe convertir al modelo de proyecto antes de continuar.

Los cambios siguientes son necesarios en el archivo de proyecto XML .csproj :

  1. Establezca el valor de PropertyGroup.De TargetFramework a net8.0.

  2. Establezca el valor de PropertyGroup.De AzureFunctionsVersion a v4.

  3. Agregue el elemento OutputType siguiente a PropertyGroup:

    <OutputType>Exe</OutputType>

  4. En la lista ItemGroup.PackageReference, reemplace la referencia de paquete a Microsoft.NET.Sdk.Functions por las referencias siguientes:

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

    Anote las referencias a otros paquetes en los espacios de nombres Microsoft.Azure.WebJobs.*. Reemplazará estos paquetes en un paso posterior.

  5. Agregue el nuevo ItemGroup siguiente:

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

Después de realizar estos cambios, el proyecto actualizado debe tener un aspecto similar al del ejemplo siguiente:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <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.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Cambiar la plataforma de destino del proyecto también puede requerir cambios en partes de la cadena de herramientas, fuera del código del proyecto. Por ejemplo, en VS Code, es posible que tenga que actualizar la configuración de extensión a través de la azureFunctions.deploySubpath configuración de usuario o el archivo .vscode/settings.json del proyecto. Compruebe si hay dependencias en la versión del entorno que puedan existir fuera del código del proyecto, como parte de los pasos de construcción o un pipeline de CI/CD.

Referencias de paquete

Al migrar al modelo de trabajo aislado, debe cambiar los paquetes a los que hace referencia la aplicación.

Si aún no lo ha hecho, actualice el proyecto para hacer referencia a las versiones estables más recientes de:

Dependiendo de los desencadenadores y enlaces que use la aplicación, es posible que la aplicación tenga que hacer referencia a un conjunto diferente de paquetes. En la tabla siguiente se muestran los reemplazos de algunas de las extensiones más usadas:

Escenario Cambios en las referencias de paquete
Desencadenador de temporizador Agregar
Microsoft.Azure.Functions.Worker.Extensions.Timer
Vinculaciones de almacenamiento Reemplazar
Microsoft.Azure.WebJobs.Extensions.Storage
con
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues y
Microsoft.Azure.Functions.Worker.Extensions.Tables
Enlaces de blob Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Enlaces de cola Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Enlaces de tabla Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.Tables
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.Tables
Enlaces de Cosmos DB Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.CosmosDB
y/o
Microsoft.Azure.WebJobs.Extensions.DocumentDB
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Enlaces de Service Bus Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.ServiceBus
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Enlaces de Event Hubs Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.EventHubs
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Enlaces de Event Grid Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.EventGrid
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Enlaces de SignalR Service Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.SignalRService
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Funciones duraderas Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.DurableTask
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Funciones duraderas
(proveedor de almacenamiento de SQL)		 Reemplace las referencias a
Microsoft.DurableTask.SqlServer.AzureFunctions
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Funciones duraderas
(proveedor de almacenamiento Netherite)		 Reemplace las referencias a
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Conexiones de SendGrid Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.SendGrid
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Enlaces de Kafka Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.Kafka
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Enlaces de RabbitMQ Reemplace las referencias a
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
con la versión más reciente de
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Inserción de dependencia
y configuración de inicio		 Elimine las referencias a
Microsoft.Azure.Functions.Extensions
(El modelo de trabajo aislado proporciona esta funcionalidad de forma predeterminada).

Consulte Enlaces admitidos para obtener una lista completa de extensiones que se deben tener en cuenta y consulte la documentación de cada extensión para obtener instrucciones de instalación completas para el modelo de proceso aislado. Asegúrese de instalar la versión estable más reciente de los paquetes que está utilizando.

Sugerencia

Los cambios en las versiones de extensión durante este proceso pueden requerir que también deba actualizar el archivo host.json. Asegúrese de leer la documentación de cada extensión que use. Por ejemplo, la extensión de Service Bus tiene cambios importantes en la estructura entre las versiones 4.x y 5.x. Para más información, consulte Enlaces de Azure Service Bus para Azure Functions.

Su aplicación del modelo de trabajo aislado no debe hacer referencia a ningún paquete en los espacios de nombres de Microsoft.Azure.WebJobs.* o Microsoft.Azure.Functions.Extensions. Si todavía existen referencias a estos elementos, deben eliminarse.

Sugerencia

La aplicación también puede depender de los tipos de SDK de Azure, ya sea como parte de los desencadenadores y enlaces o como una dependencia independiente. Deberías aprovechar esta oportunidad para actualizar estos también. Las versiones más recientes de las extensiones de Functions funcionan con las versiones más recientes del SDK de Azure para .NET, casi todos los paquetes para los que el formato es Azure.*.

archivo Program.cs

Al migrar para que se ejecute en un proceso de trabajo aislado, debe agregar un archivo Program.cs al proyecto con el siguiente contenido:

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

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

host.Run();

En este ejemplo se incluye la integración de ASP.NET Core para mejorar el rendimiento y proporcionar un modelo de programación familiar cuando la aplicación usa desencadenadores HTTP. Si no pretende usar desencadenadores HTTP, puede reemplazar la llamada a ConfigureFunctionsWebApplication por una llamada a ConfigureFunctionsWorkerDefaults. Si lo hace, puede quitar la referencia a Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore del archivo del proyecto. Sin embargo, para obtener el mejor rendimiento, incluso para las funciones con otros tipos de desencadenador, debe mantener FrameworkReference en ASP.NET Core.

El archivo Program.cs reemplaza cualquier archivo que tenga el FunctionsStartup atributo , que suele ser un archivo Startup.cs . En los lugares donde el código FunctionsStartup haría referencia a IFunctionsHostBuilder.Services, puede, en su lugar, agregar declaraciones dentro del método .ConfigureServices() del HostBuilder en su archivo Program.cs. Para más información sobre cómo trabajar con Program.cs, consulte Inicio y configuración en la guía del modelo de trabajo aislado.

Los ejemplos de Program.cs predeterminados descritos anteriormente incluyen la configuración de Application Insights. En su Program.cs, también debe configurar cualquier filtrado de registros que se aplique a los registros procedentes del código del proyecto. En el modelo de trabajo aislado, el archivo host.json solo controla los eventos emitidos por el entorno de ejecución del host de Functions. Si no configura reglas de filtrado en Program.cs, es posible que vea diferencias en los niveles de registro presentes para varias categorías en la telemetría.

Aunque puede registrar orígenes de configuración personalizados como parte de HostBuilder, se aplican de forma similar solo al código del proyecto. La plataforma también necesita la configuración de desencadenador y enlace, y esto se debe proporcionar a través de las características de configuración de la aplicación, las referencias de Key Vault o las referencias de App Configuration.

Después de mover todo de cualquier existente FunctionsStartup al archivo Program.cs , puede eliminar el FunctionsStartup atributo y la clase a la que se aplicó.

Cambios en la signatura de función

Algunos tipos clave cambian entre el modelo en proceso y el modelo de trabajador aislado. Muchos de estos se relacionan con los atributos, parámetros y tipos de valor devuelto que componen la signatura de función. Para cada una de las funciones, debe realizar cambios en:

  • Atributo de función, que también establece el nombre de la función.
  • Cómo obtiene la función un ILogger/ILogger<T>
  • Atributos y parámetros de desencadenador y enlace

El resto de esta sección le guía a través de cada uno de estos pasos.

Atributos de función

El atributo Function del modelo de trabajo aislado reemplaza al atributo FunctionName. El nuevo atributo tiene la misma signatura y la única diferencia está en el nombre. Por lo tanto, solo puede realizar un reemplazo de cadena en el proyecto.

Registro

En el modelo en proceso, podría incluir un parámetro opcional ILogger para la función, o bien podría usar la inserción de dependencias para obtener un ILogger<T>. Si la aplicación ya usó la inserción de dependencias, los mismos mecanismos funcionan en el modelo de trabajo aislado.

Sin embargo, para cualquier función que se base en el parámetro del método ILogger, tiene que hacer un cambio. Se recomienda usar la inserción de dependencias para obtener un ILogger<T>. Siga estos pasos para migrar el mecanismo de registro de la función:

  1. En la clase de función, agregue una propiedad private readonly ILogger<MyFunction> _logger; y reemplace MyFunction por el nombre de la clase de función.

  2. Cree un constructor para su clase de funciones que tome el ILogger<T> como parámetro:

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

    Reemplace ambas instancias de MyFunction en el fragmento de código anterior por el nombre de la clase de función.

  3. Para las operaciones de registro en el código de función, reemplace las referencias al parámetro ILogger por _logger.

  4. Quite el parámetro ILogger de la signatura de función.

Para más información, consulte Registro en el modelo de trabajo aislado.

Cambios de desencadenador y enlace

Al cambiar las referencias del paquete en un paso anterior, introdujo errores para los desencadenadores y enlaces que ahora puede corregir:

  1. Quite las instrucciones using Microsoft.Azure.WebJobs;.

  2. Agregue una instrucción using Microsoft.Azure.Functions.Worker;.

  3. Para cada atributo de enlace, cambie el nombre del atributo tal como se especifica en su documentación de referencia, que puede encontrar en el índice de Enlaces admitidos. En general, los nombres de atributo cambian de la siguiente manera:

    • Normalmente, los desencadenadores permanecen denominados de la misma manera. Por ejemplo, QueueTrigger es el nombre del atributo para ambos modelos.
    • Los enlaces de entrada normalmente necesitan Input agregado a su nombre. Por ejemplo, si usó el atributo CosmosDB de enlace de entrada en el modelo en proceso, el atributo ahora sería CosmosDBInput.
    • Los enlaces de salida normalmente necesitan que se añada Output a su nombre. Por ejemplo, si usó el atributo Queue de enlace de salida en el modelo en proceso, este atributo ahora sería QueueOutput.

  4. Actualice los parámetros de atributo para reflejar la versión del modelo de trabajo aislado, tal como se especifica en la documentación de referencia del enlace.

    Por ejemplo, en el modelo en proceso, un enlace de salida de blob se representa mediante un atributo [Blob(...)] que incluye una propiedad Access. En el modelo de trabajo aislado, el atributo de salida del blob sería [BlobOutput(...)]. El enlace ya no requiere la propiedad Access, por lo que ese parámetro puede eliminarse. Por lo tanto, [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] se convertiría en [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Mueva los enlaces de salida fuera de la lista de parámetros de función. Si solo tiene una vinculación de salida, puede aplicarla al tipo de retorno de la función. Si tiene varias salidas, cree una nueva clase con propiedades para cada salida y aplique los atributos a esas propiedades. Para más información, consulte Múltiples enlaces de salida.

  6. Consulte la documentación de referencia de cada vinculación para conocer los tipos a los que permite vincular. En algunos casos, es posible que tenga que cambiar el tipo. Para los enlaces de salida, si la versión del modelo en proceso usaba un IAsyncCollector<T>, puede reemplazarlo por un enlace a una matriz del tipo objetivo: T[]. También puede considerar la posibilidad de reemplazar el enlace de salida por un objeto de cliente para el servicio que representa, ya sea como el tipo de enlace de un enlace de entrada si está disponible o insertando un cliente usted mismo.

  7. Si la función incluye un parámetro IBinder, quítelo. Reemplace la funcionalidad por un objeto de cliente para el servicio que representa, ya sea como el tipo de enlace de un enlace de entrada si está disponible o insertando un cliente usted mismo.

  8. Actualice el código de función para que funcione con los nuevos tipos.

Archivo local.settings.json

El archivo local.settings.json solo se usa cuando se ejecuta localmente. Para obtener información, consulte Archivo de configuración local.

Al migrar de una ejecución en proceso a una ejecución en un proceso de trabajo aislado, debe cambiar el valor de FUNCTIONS_WORKER_RUNTIME a dotnet-isolated. Asegúrese de que el archivo local.settings.json tenga al menos los siguientes elementos:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

El valor que tiene para AzureWebJobsStorage puede ser diferente. No es necesario cambiar su valor como parte de la migración.

archivo host.json

No se requieren cambios en el archivo host.json . Sin embargo, si la configuración de Application Insights está en este archivo del proyecto de modelo en proceso, es posible que desee realizar cambios adicionales en el archivo de Program.cs . El archivo host.json solo controla el registro desde el entorno de ejecución del host de Functions y, en el modelo de trabajo aislado, algunos de estos registros proceden directamente de la aplicación, lo que proporciona más control. Consulte Administración de niveles de registro en el modelo de trabajo aislado para obtener más información sobre cómo filtrar estos registros.

Otros cambios de código

En esta sección se resaltan otros cambios de código que se deben tener en cuenta a medida que se trabaja por la migración. Estas aplicaciones no necesitan estos cambios, pero debe evaluar si alguno es relevante para sus escenarios.

Serialización de JSON

De forma predeterminada, el modelo de trabajo aislado usa System.Text.Json para la serialización JSON. Para personalizar las opciones de serializador o cambiar a JSON.NET (Newtonsoft.Json), consulte Personalización de la serialización JSON.

Filtrado y niveles de registro de Application Insights

Los registros se pueden enviar a Application Insights desde el entorno de ejecución del host de Functions y el código del proyecto. El host.json permite configurar reglas para el registro del anfitrión, pero para controlar los registros que provienen de su código, debe configurar reglas de filtrado como parte de su archivo Program.cs. Consulte Administración de niveles de registro en el modelo de trabajo aislado para obtener más información sobre cómo filtrar estos registros.

Migraciones de funciones de ejemplo

Ejemplo de desencadenador HTTP

Un desencadenador HTTP para el modelo en proceso podría tener un aspecto similar al del ejemplo siguiente:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Un desencadenador HTTP para la versión migrada podría ser como el siguiente ejemplo:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

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

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Actualización de la aplicación de funciones en Azure

La actualización de la aplicación de funciones al modelo aislado implica dos cambios que deben completarse juntos, ya que si solo se completa uno, la aplicación se encuentra en un estado de error. Ambos cambios también hacen que el proceso de la aplicación se reinicie. Por estos motivos, debe realizar la actualización mediante un espacio de ensayo. Las ranuras de ensayo ayudan a minimizar el tiempo de inactividad de la aplicación y permiten probar y comprobar el código migrado con la configuración actualizada en Azure. Después, puede implementar la aplicación totalmente migrada en el espacio de producción mediante una operación de intercambio.

Importante

Cuando la carga implementada de una aplicación no coincide con el tiempo de ejecución configurado, se encuentra en un estado de error. Durante el proceso de migración, la aplicación se coloca en este estado, idealmente solo temporalmente. Las ranuras de implementación ayudan a mitigar el efecto de esto, ya que el estado de error se resolverá en el entorno de ensayo (no producción) antes de que los cambios se apliquen como una única actualización al entorno de producción. Las ranuras también defienden cualquier error y le permiten detectar cualquier otro problema antes de llegar a producción.

Durante el proceso, es posible que todavía vea errores en los registros procedentes de la ranura de almacenamiento provisional (no de producción). Esto es de esperar, aunque estos deberían desaparecer a medida que completas los pasos. Antes de realizar la operación de intercambio de ranuras, debe confirmar que estos errores dejan de generarse y que la aplicación funciona según lo previsto.

Siga estos pasos para usar ranuras de implementación para actualizar la aplicación de funciones al modelo de trabajo aislado:

  1. Cree un espacio de implementación si aún no lo ha hecho. También puede familiarizarse con el proceso de intercambio de ranuras y asegurarse de que puede realizar actualizaciones en la aplicación existente con una interrupción mínima.

  2. Cambie la configuración de la ranura de prueba (no producción) para usar el modelo de trabajo aislado estableciendo la configuración de aplicación FUNCTIONS_WORKER_RUNTIME en dotnet-isolated. FUNCTIONS_WORKER_RUNTIME no debe marcarse como configuración de ranura.

    Si también tiene como destino una versión diferente de .NET como parte de la actualización, también debe cambiar la configuración de la pila. Para ello, consulte Actualizar la configuración de la pila. Puede usar las mismas instrucciones para cualquier actualización futura de la versión de .NET que realice.

    Si tiene algún aprovisionamiento de infraestructura automatizado, como una canalización de CI/CD, asegúrese de que las automatizaciones también se actualizan para mantener FUNCTIONS_WORKER_RUNTIME establecido en dotnet-isolated y para tener como destino la versión correcta de .NET.

  3. Publique el proyecto migrado en la ranura de almacenamiento provisional (no de producción) de la aplicación de funciones.

    Si usa Visual Studio para publicar un proyecto de modelo de trabajador aislado en una aplicación o espacio existente que utiliza el modelo dentro del proceso, puede completar el paso anterior simultáneamente. Si no completó el paso anterior, Visual Studio le pedirá que actualice la aplicación de funciones durante la implementación. Visual Studio presenta esto como una sola operación, pero estas siguen siendo dos operaciones independientes. Es posible que todavía vea errores en los registros desde la ranura de almacenamiento provisional (no de producción) durante el estado provisional.

  4. Confirme que su aplicación funciona según lo previsto en el entorno de ensayo (no en producción).

  5. Realice una operación de intercambio de ranuras para aplicar los cambios realizados en la ranura de almacenamiento provisional (no producción) al espacio de producción. Un intercambio de ranuras se produce en forma de una única actualización, lo que evita introducir el estado de error provisional en tu entorno de producción.

  6. Confirme que la aplicación funciona según lo previsto en el espacio de producción.

Una vez completados estos pasos, la migración se completa y la aplicación se ejecuta en el modelo aislado. Felicidades. Repita los pasos de esta guía según sea necesario para cualquier otra aplicación que necesite la migración.

Paso siguiente

Obtener más información sobre el modelo de trabajo aislado