Comparteix a través de

Migración de aplicaciones de .NET desde el modelo en proceso al modelo de trabajo aislado

  • Article

Importante

El soporte técnico finalizará para el modelo en proceso 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 seguir las guías para actualizar la versión del 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.

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 que Azure PowerShell está actualmente configurado para usar. 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 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 Functions1,2
.NET 9 Versión preliminar3 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 6 LTS (finales de soporte técnico 12 de noviembre de 2024) 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 teniendo soporte técnico completo, debería migrar sus aplicaciones al modelo de trabajo aislado.

3Vea versiones preliminares de .NET en el modelo de trabajo aislado para obtener más información sobre la compatibilidad, las restricciones actuales y las instrucciones para usar la versión preliminar.

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 (versión preliminar) o .NET 6. Si necesita tener como destino estas versiones, puede adaptar los ejemplos de .NET 8.

Preparación para la migración

Si aún no lo ha hecho, identifique la lista de aplicaciones que necesitan migrarse en la suscripción actual de Azure mediante Azure PowerShell.

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, hará lo siguiente:

  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. Estos pasos suponen un proyecto de C# local y, si se usa la aplicación en lugar de usar el script de C# (archivos .csx), debe convertir al modelo de proyecto antes de continuar.

Sugerencia

Si va a pasar a una versión LTS o STS de .NET, el Asistente para actualización de .NET se puede usar 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 de .csproj que usa .NET 6 en la versión 4.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.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:

Estos pasos suponen un proyecto de C# local y, si se usa la aplicación en lugar de usar el script de C# (archivos .csx), debe convertir al modelo de proyecto antes de continuar.

Los siguientes cambios 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 de los espacios de nombres de 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 azureFunctions.deploySubpath a través de la configuración de usuario o el archivo .vscode/settings.json del proyecto. Compruebe si hay dependencias en la versión del marco que puede existir fuera del código del proyecto, como parte de los pasos de compilación o una canalización 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 Sumar
Microsoft.Azure.Functions.Worker.Extensions.Timer
Enlaces de Storage Sustituya
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
Enlaces 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 de destino.

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.

La 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 quedan referencias a estos, debe quitarlas.

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ía aprovechar esta oportunidad para actualizar también esto. 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 ejecutar en un proceso de trabajo aislado, debe agregar un archivo Program.cs a su 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 reemplazará cualquier archivo que tenga el atributo FunctionsStartup, que suele ser un archivo Startup.cs. En los lugares donde su código FunctionsStartup haría referencia a IFunctionsHostBuilder.Services, puede agregar en su lugar instrucciones dentro del método .ConfigureServices() del HostBuilder en su 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 anteriores incluyen la configuración de la integración de Application Insights para el modelo de trabajo aislado. 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 perciba 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, tenga en cuenta que 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.

Una vez que haya trasladado todo de cualquier FunctionsStartup existente al archivo Program.cs, podrá eliminar el atributo FunctionsStartup y la clase a la que se aplicó.

Cambios en la signatura de función

Algunos tipos de clave cambian entre el modelo en proceso y el modelo de trabajo 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:

  • El 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 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 suelen necesitar "Output" agregado 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 un enlace de salida, puede aplicarlo al tipo de valor devuelto 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 enlace para ver los tipos a los que permite enlazar. 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 en la ejecución local. 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 código del archivo host.json. Sin embargo, si la configuración de Application Insights proviene de este archivo del proyecto de modelo en proceso, es posible que quiera realizar cambios adicionales en el archivo 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 cual 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. No todas las aplicaciones 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 de JSON. Para personalizar las opciones del serializador o cambiar a JSON.NET (Newtonsoft.Json), consulte estas instrucciones.

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. host.json permite configurar reglas para el registro de host, pero para controlar los registros procedentes del código, deberá configurar reglas de filtrado como parte de 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 una ranura 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, estará en un estado de error. Durante el proceso de migración, colocará la aplicación en este estado, idealmente solo de forma temporal. Las ranuras de implementación ayudan a mitigar el impacto de esto, ya que el estado de error se resolverá en el entorno de ensayo (no de 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 se espera, aunque estos deben desaparecer a medida que avanza en 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 una ranura 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 ensayo (no de producción) para usar el modelo de trabajo aislado estableciendo la configuración de la 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 las instrucciones para actualizar la configuración de la pila del modelo de trabajo aislado. Usará las mismas instrucciones para las futuras actualizaciones 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 ensayo (no de producción) de la aplicación de funciones.

    Si usa Visual Studio para publicar un proyecto de modelo de trabajo aislado en una aplicación o ranura existente que use el modelo en proceso, también puede completar el paso anterior al mismo tiempo. 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 ensayo (no de producción) durante el estado provisional.

  4. Confirme que la aplicación funciona según lo previsto en la ranura de ensayo (no de producción).

  5. Realice una operación de intercambio de ranuras. Esto aplica los cambios realizados en la ranura de ensayo (no de producción) a la ranura de producción. Un intercambio de ranuras se produce como una única actualización, lo que evita introducir el estado de error provisional en el entorno de producción.

  6. Confirme que la aplicación funciona según lo previsto en la ranura 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 migrar.

Pasos siguientes

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