Перенос приложений .NET из модели внутрипроцессной в изолированную рабочую модель

Внимание

Поддержка будет завершена для модели в процессе 10 ноября 2026 г. Настоятельно рекомендуется перенести приложения в изолированную рабочую модель, следуя инструкциям в этой статье.

В этой статье описывается процесс безопасного переноса приложения-функции .NET из модели внутрипроцесснойв изолированную рабочую модель. Дополнительные сведения о высоких различиях между этими моделями см. в сравнении режима выполнения.

В этом руководстве предполагается, что приложение работает в среде выполнения функций версии 4.x. В противном случае следует следовать руководствам по обновлению версии узла:

• Перенос приложений из Функции Azure версии 2.x и 3.x на версию 4.x
• Перевод приложений с Функций Azure версии 1.x на версию 4.x

Эти руководства по миграции версий узла также помогут выполнить миграцию в изолированную рабочую модель при работе с ними.

Определение приложений-функций для миграции

Используйте следующий скрипт Azure PowerShell, чтобы создать список приложений-функций в подписке, которые в настоящее время используют модель внутрипроцессного процесса.

В скрипте используется подписка, которую Azure PowerShell в настоящее время настроена для использования. Вы можете изменить подписку, сначала запустив Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' и заменив <YOUR SUBSCRIPTION ID> идентификатором подписки, которую вы хотите оценить.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Выбор целевой версии .NET

В среде выполнения функций версии 4.x приложение-функция .NET предназначено для .NET 6 при использовании модели в процессе.

При переносе приложения-функции у вас есть возможность выбрать целевую версию .NET. Проект C# можно обновить до одной из следующих версий .NET, поддерживаемых функциями версии 4.x:

Версия .NET	Тип выпуска политики поддержки .NET	Модельпроцесса функций 1,3
.NET 82	LTS	Изолированная рабочая модель
.NET 7	STS (окончание поддержки 14 мая 2024 г.)	Изолированная рабочая модель
.NET 6	LTS (окончание поддержки 12 ноября 2024 г.)	Изолированная рабочая модель, Модель в процессе3
.NET Framework 4.8	См. политику	Изолированная рабочая модель

¹ Изолированная рабочая модель поддерживает долгосрочную поддержку (LTS) и стандартные версии .NET, а также платформа .NET Framework. Модель в процессе поддерживает только выпуски LTS .NET. Полное сравнение функций и функций двух моделей см. в разделе "Различия между процессом и изоляцией рабочего процесса .NET Функции Azure".

² .NET 8 пока не поддерживается в модели в процессе, хотя она доступна в изолированной рабочей модели. Сведения о планах .NET 8, включая будущие варианты для модели в процессе, см. в статье Функции Azure "Обновление стратегии".

³ Поддержка заканчивается для модели в процессе 10 ноября 2026 года. Дополнительные сведения см . в этом объявлении о поддержке. Для непрерывной поддержки следует перенести приложения в изолированную рабочую модель.

Совет

Рекомендуется обновить до .NET 8 в изолированной рабочей модели. Это обеспечивает быстрый путь миграции к полностью выпущенной версии с самым длинным окном поддержки из .NET.

В этом руководстве нет конкретных примеров для .NET 7 или .NET 6. Если вам нужно настроить эти версии, можно адаптировать примеры .NET 8.

Подготовка к переносу

Если вы еще не сделали этого, определите список приложений, которые необходимо перенести в текущей подписке Azure с помощью Azure PowerShell.

Перед переносом приложения в изолированную рабочую модель необходимо тщательно просмотреть содержимое этого руководства и ознакомиться с функциями изолированной рабочей модели и различиями между двумя моделями.

Чтобы перенести приложение, выполните следующие действия.

1. Выполните действия, описанные в разделе "Миграция локального проекта", чтобы перенести локальный проект в изолированную рабочую модель.
2. После переноса проекта полностью протестируйте приложение локально с помощью версии 4.x Функции Azure Core Tools.
3. Обновите приложение-функцию в Azure до изолированной модели.

Перенос локального проекта

В этом разделе описаны различные изменения, которые необходимо внести в локальный проект, чтобы переместить его в изолированную рабочую модель. Некоторые шаги изменяются на основе целевой версии .NET. Используйте вкладки, чтобы выбрать инструкции, соответствующие требуемой версии. В этих шагах предполагается, что локальный проект C# и если приложение вместо этого использует скрипт C# (.csx файлы), перед продолжением следует преобразовать в модель проекта.

Совет

При переходе на LTS или STS-версию .NET помощник по обновлению .NET можно использовать для автоматического внесения многих изменений, упоминание указанных в следующих разделах.

Во-первых, вы преобразуете файл проекта и обновите зависимости. По мере выполнения вы увидите ошибки сборки для проекта. В последующих шагах необходимо внести соответствующие изменения, чтобы удалить эти ошибки.

Файл проекта

Следующий пример — .csproj это файл проекта, использующий .NET 6 в версии 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>

Используйте одну из следующих процедур, чтобы обновить этот XML-файл для запуска в изолированной рабочей модели:

.NET 8

В этих шагах предполагается, что локальный проект C# и если приложение вместо этого использует скрипт C# (.csx файлы), перед продолжением следует преобразовать в модель проекта.

В XML-файле проекта требуются .csproj следующие изменения:

1. Задайте значение PropertyGroup.TargetFramework изменено на net8.0.

2. Задайте значение PropertyGroup.AzureFunctionsVersion изменено на v4.

3. Добавьте следующий OutputType элемент в :PropertyGroup

   <OutputType>Exe</OutputType>
   

4. ItemGroupВ .PackageReference список, замените ссылку на Microsoft.NET.Sdk.Functions пакет следующими ссылками:

     <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" />
   

   Запишите ссылки на другие пакеты в Microsoft.Azure.WebJobs.* пространствах имен. Вы замените эти пакеты на следующем шаге.

5. Добавьте следующее новое:ItemGroup

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

После внесения этих изменений обновленный проект должен выглядеть следующим образом:

<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>

.NET Framework 4.8

В этих шагах предполагается, что локальный проект C# и если приложение вместо этого использует скрипт C# (.csx файлы), перед продолжением следует преобразовать в модель проекта.

В XML-файле проекта требуются .csproj следующие изменения:

1. Задайте значение PropertyGroup.TargetFramework изменено на net48.

2. Задайте значение PropertyGroup.AzureFunctionsVersion изменено на v4.

3. Добавьте следующий OutputType элемент в :PropertyGroup

   <OutputType>Exe</OutputType>
   

4. ItemGroupВ .PackageReference список, замените ссылку на Microsoft.NET.Sdk.Functions пакет следующими ссылками:

     <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
     <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
     <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
     <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
     <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
   

   Запишите ссылки на другие пакеты в Microsoft.Azure.WebJobs.* пространствах имен. Вы замените эти пакеты на следующем шаге.

5. Добавьте следующее новое:ItemGroup

   <ItemGroup>
     <Folder Include="Properties\" />
   </ItemGroup>
   

После внесения этих изменений обновленный проект должен выглядеть следующим образом:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
      <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>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

Ссылки на пакеты

При миграции в изолированную рабочую модель необходимо изменить пакеты, на которые ссылается приложение.

Если вы еще не сделали этого, обновите проект, чтобы ссылаться на последние стабильные версии:

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

В зависимости от триггеров и привязок, которые использует приложение, может потребоваться ссылаться на другой набор пакетов. В следующей таблице показаны замены некоторых наиболее часто используемых расширений:

Сценарий	Изменения ссылок на пакеты
Триггер по таймеру	Добавить Microsoft.Azure.Functions.Worker.Extensions.Timer
Привязки хранилища	Replace Microsoft.Azure.WebJobs.Extensions.Storage на Microsoft.Azure.Functions.Worker.Extensions. служба хранилища. Большие двоичные объекты, Microsoft.Azure.Functions.Worker.Extensions. служба хранилища. Очереди и Microsoft.Azure.Functions.Worker.Extensions.Tables
Привязки больших двоичных объектов	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.Storage.Blobs с последней версией Microsoft.Azure.Functions.Worker.Extensions. служба хранилища. Большие двоичные объекты
Привязки очередей	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.Storage.Queues с последней версией Microsoft.Azure.Functions.Worker.Extensions. служба хранилища. Очереди
Привязки таблиц	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.Tables с последней версией Microsoft.Azure.Functions.Worker.Extensions.Tables
Привязки Cosmos DB	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.CosmosDB и (или) Microsoft.Azure.WebJobs.Extensions.DocumentDB с последней версией Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Привязки служебной шины	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.ServiceBus с последней версией Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Привязки Центров событий	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.EventHubs с последней версией Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Привязки сетки событий	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.EventGrid с последней версией Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Привязки Службы SignalR	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.SignalRService с последней версией Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Устойчивые функции	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.DurableTask с последней версией Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Устойчивые функции (поставщик хранилища SQL)	Замена ссылок на Microsoft.DurableTask.SqlServer.AzureFunctions с последней версией Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Устойчивые функции (поставщик хранилища Netherite)	Замена ссылок на Microsoft.Azure.DurableTask.Netherite.AzureFunctions с последней версией Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Привязки SendGrid	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.SendGrid с последней версией Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Привязки Kafka	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.Kafka с последней версией Microsoft.Azure.Functions.Worker.Extensions.Kafka
Привязки RabbitMQ	Замена ссылок на Microsoft.Azure.WebJobs.Extensions.RabbitMQ с последней версией Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Внедрение зависимостей и конфигурация запуска	Удаление ссылок на Microsoft.Azure.Functions.Extensions (Изолированная рабочая модель предоставляет эту функцию по умолчанию.)

Ознакомьтесь с поддерживаемыми привязками для полного списка расширений, которые следует рассмотреть, и ознакомьтесь с документацией по каждому расширению, чтобы получить полные инструкции по установке для изолированной модели процесса. Не забудьте установить последнюю стабильную версию всех целевых пакетов.

Совет

Любые изменения версий расширений во время этого процесса могут потребовать обновления host.json файла. Обязательно ознакомьтесь с документацией по каждому используемому расширению. Например, расширение служебная шина имеет критические изменения в структуре между версиями 4.x и 5.x. Дополнительные сведения см. в Служебная шина Azure привязках для Функции Azure.

Приложение изолированной рабочей модели не должно ссылаться на пакеты в Microsoft.Azure.WebJobs.* пространствах имен или Microsoft.Azure.Functions.Extensions. Если у вас есть оставшиеся ссылки на них, их следует удалить.

Совет

Ваше приложение также может зависеть от типов azure SDK, как часть триггеров и привязок, так и в качестве автономной зависимости. Вы должны воспользоваться этой возможностью, чтобы обновить их, а также. Последние версии расширений функций работают с последними версиями пакета SDK Azure для .NET, почти все пакеты, для которых это форма Azure.*.

файл Program.cs

При миграции на выполнение в изолированном рабочем процессе необходимо добавить Program.cs файл в проект со следующим содержимым:

.NET 8

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();

Этот пример включает интеграцию ASP.NET Core для повышения производительности и предоставления знакомой модели программирования при использовании триггеров HTTP в приложении. Если вы не планируете использовать триггеры HTTP, можно заменить вызов ConfigureFunctionsWebApplication вызовом ConfigureFunctionsWorkerDefaults. При этом можно удалить ссылку Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore на файл проекта. Однако для оптимальной производительности даже для функций с другими типами триггеров следует сохранить FrameworkReference ASP.NET Core.

.NET Framework 4.8

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

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

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

Файл Program.cs заменит любой файл, имеющий FunctionsStartup атрибут, который обычно является файлом Startup.cs . В местах, где FunctionsStartup будет ссылаться IFunctionsHostBuilder.Servicesваш код, можно вместо этого добавлять инструкции в .ConfigureServices() метод HostBuilder в вашем Program.csкоде. Дополнительные сведения о работе с Program.csней см. в руководстве по изолированной рабочей модели.

Program.cs Приведенные выше примеры включают настройку интеграции Application Аналитика для изолированной рабочей модели. В вашем Program.csприложении также необходимо настроить фильтрацию журналов, которая должна применяться к журналам, поступающим из кода в проекте. В изолированной рабочей модели host.json файл управляет только событиями, создаваемыми средой выполнения узла Функций. Если правила Program.csфильтрации не настроены, могут возникнуть различия в уровнях журналов, присутствующих для различных категорий в телеметрии.

Хотя вы можете зарегистрировать пользовательские источники конфигурации в рамках HostBuilderпрограммы, обратите внимание, что они аналогично применяются только к коду в проекте. Настройка триггера и привязки также необходима для платформы, и это должно быть предоставлено с помощью параметров приложения, ссылок Key Vault или Конфигурация приложений ссылок на функции.

После перемещения всего из любого существующего FunctionsStartupProgram.cs в файл можно удалить FunctionsStartup атрибут и класс, к который он был применен.

Изменения подписи функции

Некоторые ключевые типы изменяются между внутрипроцессной моделью и изолированной рабочей моделью. Многие из них относятся к атрибутам, параметрам и возвращаемым типам, составляющим сигнатуру функции. Для каждой функции необходимо внести изменения в следующее:

• Атрибут функции (который также задает имя функции)
• Получение функции ILogger/ILogger<T>
• Атрибуты и параметры триггера и привязки

В остальной части этого раздела вы узнаете, как выполнить все эти действия.

Атрибуты функций

Атрибут FunctionName заменяется атрибутом Function в изолированной рабочей модели. Новый атрибут имеет ту же сигнатуру, и единственное различие в имени. Поэтому вы можете просто выполнить замену строки в проекте.

Ведение журнала

В модели внутрипроцессного процесса можно включить дополнительный ILogger параметр в функцию или использовать внедрение зависимостей для получения ILogger<T>. Если вы уже использовали внедрение зависимостей, то те же механизмы работают в изолированной рабочей модели.

Однако для любых функций, зависящих от ILogger параметра метода, необходимо внести изменения. Рекомендуется использовать внедрение зависимостей для получения ILogger<T>. Чтобы перенести механизм ведения журнала функции, выполните следующие действия.

1. В классе функции добавьте private readonly ILogger<MyFunction> _logger; свойство, заменив MyFunction имя класса функции.

2. Создайте конструктор для класса функции, который принимает в ILogger<T> качестве параметра:

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

   Замените оба экземпляра MyFunction в фрагменте кода выше именем класса функции.

3. Для операций ведения журнала в коде ILogger функции замените ссылки на параметр _logger.

4. ILogger Удалите параметр из подписи функции.

Дополнительные сведения см. в разделе "Ведение журнала" в изолированной рабочей модели.

Изменения триггера и привязки

При изменении ссылок на пакет на предыдущем шаге вы внесли ошибки для триггеров и привязок, которые будут исправлены:

1. Удалите все using Microsoft.Azure.WebJobs; инструкции.

2. Добавьте инструкцию using Microsoft.Azure.Functions.Worker; .

3. Для каждого атрибута привязки измените имя атрибута, как указано в справочной документации, которую можно найти в индексе поддерживаемых привязок . Как правило, имена атрибутов изменяются следующим образом:

   • Триггеры обычно остаются именованными так же. Например, QueueTrigger это имя атрибута для обеих моделей.
   • Входные привязки обычно требуют добавления входных привязок в их имя. Например, если в модели внутрипроцессной модели использовался атрибут входной CosmosDB привязки, теперь это будет CosmosDBInput.
   • Выходные привязки обычно требуют добавления "Output" в их имя. Например, если в модели внутрипроцессной модели использовался атрибут выходной Queue привязки, теперь это будет QueueOutput.

4. Обновите параметры атрибута, чтобы отразить изолированную версию рабочей модели, как указано в справочной документации привязки.

   Например, в модели внутрипроцессного процесса выходная привязка большого двоичного объекта представлена атрибутом [Blob(...)] , который включает Access свойство. В изолированной рабочей модели выходной атрибут большого двоичного объекта будет [BlobOutput(...)]. Привязка больше не требует Access свойства, чтобы этот параметр можно было удалить. Так [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] стало бы [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

5. Перемещение выходных привязок из списка параметров функции. Если у вас есть только одна выходная привязка, это можно применить к типу возвращаемой функции. Если у вас несколько выходных данных, создайте новый класс со свойствами для каждого вывода и примените атрибуты к этим свойствам. Дополнительные сведения см. в разделе "Несколько выходных привязок".

6. Ознакомьтесь со справочной документацией по каждой привязке для типов, к которых можно привязаться. В некоторых случаях может потребоваться изменить тип. Для выходных привязок, если используется IAsyncCollector<T>версия модели в процессе, ее можно заменить привязкой к массиву целевого типа: T[] Вы также можете заменить выходную привязку клиентским объектом для службы, которая она представляет, либо как тип привязки входной привязки, если она доступна, либо путем внедрения клиента самостоятельно.

7. Если функция содержит IBinder параметр, удалите его. Замените функциональность клиентским объектом службы, который он представляет, либо как тип привязки для входной привязки, если он доступен, либо путем внедрения клиента самостоятельно.

8. Обновите код функции, чтобы работать с любыми новыми типами.

файле local.settings.json

Файл local.settings.json используется только при локальном запуске. Дополнительные сведения см. в файле локальных параметров.

При переходе от выполнения процесса к выполнению в изолированном рабочем процессе необходимо изменить FUNCTIONS_WORKER_RUNTIME значение на "dotnet-isolated". Убедитесь, что файл local.settings.json содержит по крайней мере следующие элементы:

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

Значение, настроенное для AzureWebJobs служба хранилища, может отличаться. Изменить его значение в рамках миграции не нужно.

файл host.json

Изменения в файле не требуются host.json . Однако если ваша конфигурация приложения Аналитика в этом файле из проекта модели в процессе, может потребоваться внести дополнительные изменения в Program.cs файл. Файл host.json управляет ведением журнала только из среды выполнения узла Функций и в изолированной рабочей модели некоторые из этих журналов приходят непосредственно из приложения, что дает вам больше контроля. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".

Другие изменения кода

В этом разделе рассматриваются другие изменения кода, которые следует учитывать при работе с миграцией. Эти изменения не требуются для всех приложений, но следует оценить, имеют ли они отношение к вашим сценариям.

Сериализация JSON

По умолчанию изолированная рабочая модель используется System.Text.Json для сериализации JSON. Сведения о настройке параметров сериализатора или переключении на JSON.NET (Newtonsoft.Json) см . в этих инструкциях.

Уровни журналов и фильтрация приложений Аналитика

Журналы можно отправлять в приложение Аналитика из среды выполнения узла функций и кода в проекте. Это host.json позволяет настраивать правила для ведения журнала узлов, но управлять журналами, поступающими из кода, необходимо настроить правила фильтрации в рамках вашего кода Program.cs. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".

Примеры миграций функций

Пример триггера HTTP

Триггер HTTP для модели в процессе может выглядеть следующим образом:

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"]}!");
        }
    }
}

Триггер HTTP для перенесенной версии может выглядеть следующим образом:

.NET 8

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"]}!");
        }
    }
}

.NET Framework 4.8

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

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

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

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

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Обновление приложения-функции в Azure

Обновление приложения-функции до изолированной модели состоит из двух этапов:

1. Измените конфигурацию приложения-функции, чтобы использовать изолированную модель, задав FUNCTIONS_WORKER_RUNTIME для параметра приложения значение dotnet-isolated. Убедитесь, что любая автоматизация развертывания аналогично обновляется.
2. Опубликуйте перенесенный проект в обновленном приложении-функции.

При использовании Visual Studio для публикации проекта изолированной рабочей модели в существующем приложении-функции, использующем модель внутрипроцессного процесса, вам будет предложено разрешить Visual Studio обновить приложение-функцию во время развертывания. Это выполняет оба шага одновременно.

Если вам нужно свести к минимуму время простоя, рассмотрите возможность использования промежуточного слота для тестирования и проверки перенесенного кода с обновленной конфигурацией в Azure. Затем можно развернуть полностью перенесенное приложение в рабочий слот с помощью операции переключения.

После выполнения этих действий приложение будет полностью перенесено в изолированную модель. Поздравляем! Повторите действия из этого руководства по мере необходимости для любых других приложений, требующих миграции.

Следующие шаги

Дополнительные сведения об изолированной рабочей модели