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

Статья
04/07/2024

Внимание

Java не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы хотите перенести приложение Java с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

TypeScript не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы хотите перенести приложение TypeScript с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

PowerShell не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы хотите перенести приложение PowerShell с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

Python не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы хотите перенести приложение Python с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

Поддержка будет завершена для среды выполнения Функции Azure версии 1.x 14 сентября 2026 г. Настоятельно рекомендуется перенести приложения в версию 4.x, следуя инструкциям в этой статье.

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

Если вы используете среду выполнения версии 1.x в Azure Stack Hub, сначала ознакомьтесь с рекомендациями по Azure Stack Hub .

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

Используйте следующий сценарий PowerShell для создания списка приложений-функций в подписке, предназначенных для текущей версии 1.x:

$Subscription = '<YOUR SUBSCRIPTION ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*1*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

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

В среде выполнения функций версии 1.x приложение-функция C# предназначено для платформа .NET Framework.

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

Версия .NET	Тип выпуска политики поддержки .NET	Модель^{процесса функций 1,2}
.NET 9	Предварительная версия³	Изолированная рабочая модель
.NET 8	LTS (окончание поддержки 10 ноября 2026 г.)	Изолированная рабочая модель, Модель в процессе²
.NET 6	LTS (окончание поддержки 12 ноября 2024 г.)	Изолированная рабочая модель, Модель в процессе²
.NET Framework 4.8	См. политику	Изолированная рабочая модель

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

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

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

Совет

Если приложение не зависит от библиотеки или API, доступной только для платформа .NET Framework, рекомендуется обновить до .NET 8 в изолированной рабочей модели. Многие приложения в целевой версии 1.x платформа .NET Framework только потому, что это то, что было доступно при создании. Дополнительные возможности доступны для более поздних версий .NET, и если ваше приложение не вынуждено оставаться на платформа .NET Framework из-за зависимости, следует нацелиться на более новую версию. .NET 8 — это полностью выпущенная версия с самым длинным окном поддержки из .NET.

Хотя вместо этого можно использовать модель в процессе, это не рекомендуется, если ее можно избежать. Поддержка будет завершена для модели в процессе 10 ноября 2026 года, поэтому перед этим вам потребуется перейти к изолированной рабочей модели. Это при миграции на версию 4.x уменьшит общее количество необходимых усилий, и изолированная рабочая модель даст вашему приложению дополнительные преимущества, включая возможность более легко использовать будущие версии .NET. При переходе к изолированной рабочей модели помощник по обновлению .NET также может обрабатывать многие необходимые изменения кода.

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

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

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

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

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

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

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

В следующих разделах описаны обновления, которые необходимо внести в файлы проекта C#, чтобы иметь возможность выполняться в одной из поддерживаемых версий .NET в Функциях версии 4.x. Отображаемые обновления являются общими для большинства проектов. Код проекта может требовать обновления, не упомянутые в этой статье, особенно при использовании пользовательских пакетов NuGet.

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

Выберите вкладку, соответствующую целевой версии .NET, и требуемую модель процесса (внутрипроцессный или изолированный рабочий процесс).

Совет

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

Файл проекта

Следующий пример — это файл проекта, работающий .csproj в версии 1.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </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-файл для запуска в Функциях версии 4.x:

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

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

Задайте значение PropertyGroup.TargetFramework изменено на net8.0.
Задайте значение PropertyGroup.AzureFunctionsVersion изменено на v4.
Добавьте следующий OutputType элемент в :PropertyGroup
```
<OutputType>Exe</OutputType>
```

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.* пространствах имен. Вы замените эти пакеты на следующем шаге.

Добавьте следующее новое: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>

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

Задайте значение PropertyGroup.TargetFramework изменено на net48.
Задайте значение PropertyGroup.AzureFunctionsVersion изменено на v4.
Добавьте следующий OutputType элемент в :PropertyGroup
```
<OutputType>Exe</OutputType>
```

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

Добавьте следующее новое: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>

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

Задайте значение PropertyGroup.TargetFramework изменено на net8.0.
Задайте значение PropertyGroup.AzureFunctionsVersion изменено на v4.
Замените существующий ItemGroup.PackageReference список со следующими ItemGroupпараметрами:
```
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
</ItemGroup>
```

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

<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.4.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

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

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

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

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

Сценарий	Изменения ссылок на пакеты
Триггер по таймеру	Добавить Microsoft.Azure.Functions.Worker.Extensions.Timer
Привязки хранилища	Replace `Microsoft.Azure.WebJobs.Extensions.Storage` на Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs, Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues и Microsoft.Azure.Functions.Worker.Extensions.Tables
Привязки больших двоичных объектов	Замена ссылок на `Microsoft.Azure.WebJobs.Extensions.Storage.Blobs` с последней версией Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Привязки очередей	Замена ссылок на `Microsoft.Azure.WebJobs.Extensions.Storage.Queues` с последней версией Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Привязки таблиц	Замена ссылок на `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.*.

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

Сценарий	Изменения ссылок на пакеты
Триггер по таймеру	Добавить Microsoft.Azure.Functions.Worker.Extensions.Timer
Привязки хранилища	Replace `Microsoft.Azure.WebJobs.Extensions.Storage` на Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs, Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues и Microsoft.Azure.Functions.Worker.Extensions.Tables
Привязки больших двоичных объектов	Замена ссылок на `Microsoft.Azure.WebJobs.Extensions.Storage.Blobs` с последней версией Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Привязки очередей	Замена ссылок на `Microsoft.Azure.WebJobs.Extensions.Storage.Queues` с последней версией Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Привязки таблиц	Замена ссылок на `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` (Изолированная рабочая модель предоставляет эту функцию по умолчанию.)

Совет

Обновите проект, чтобы ссылаться на последнюю стабильную версию Microsoft.NET.Sdk.Functions.

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

Совет

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

файл Program.cs

В большинстве случаев миграция требует добавления в проект следующего program.cs файла:

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.

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

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

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

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

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

файл host.json

Параметры в файле host.json применяются на уровне приложения-функции как локально, так и в Azure. В версии 1.x файл host.json пуст или содержит некоторые параметры, которые применяются ко всем функциям в приложении-функции. Дополнительные сведения см. в Host.json версии 1. Если файл host.json имеет значения параметров, просмотрите формат host.json версии 2 для любых изменений.

Чтобы запуститься в версии 4.x, необходимо добавить "version": "2.0" в файл host.json. Также следует добавить logging в конфигурацию, как показано в следующих примерах:

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

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

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

файле local.settings.json

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

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

При переходе на версию 4.x убедитесь, что файл local.settings.json содержит по крайней мере следующие элементы:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Примечание.

При переходе от выполнения процесса к выполнению в изолированном рабочем процессе необходимо изменить FUNCTIONS_WORKER_RUNTIME значение на "dotnet-isolated".

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Примечание.

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1"
    }
}

Примечание.

При выборе целевого объекта .NET 8 с помощью модели в процессе необходимо задать FUNCTIONS_WORKER_RUNTIME значение dotnet и задать FUNCTIONS_INPROC_NET8_ENABLED значение "1".

Изменения имени класса

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

Версия 1.x	.NET 8
`FunctionName` (атрибут)	`Function` (атрибут)
`TraceWriter`	`ILogger<T>`, `ILogger`
`HttpRequestMessage`	`HttpRequestData`, `HttpRequest` (использование интеграции ASP.NET Core)
`HttpResponseMessage`	`HttpResponseData`, `IActionResult` (использование интеграции ASP.NET Core)

Версия 1.x	.NET Framework 4.8
`FunctionName` (атрибут)	`Function` (атрибут)
`TraceWriter`	`ILogger<T>`, `ILogger`
`HttpRequestMessage`	`HttpRequestData`
`HttpResponseMessage`	`HttpResponseData`

Версия 1.x	.NET 6 (в процессе)
`FunctionName` (атрибут)	`FunctionName` (атрибут)
`TraceWriter`	`ILogger<T>`, `ILogger`
`HttpRequestMessage`	`HttpRequest`
`HttpResponseMessage`	`IActionResult`

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

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

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

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

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

Уровни журналов Application Insights и фильтрация

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

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

Уровни журналов Application Insights и фильтрация

Шаблон триггера HTTP

Большинство изменений кода между версией 1.x и версией 4.x можно увидеть в триггерных функциях HTTP. Шаблон триггера HTTP для версии 1.x выглядит следующим образом:

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<HttpResponseMessage> 
            Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", 
            Route = null)]HttpRequestMessage req, TraceWriter log)
        {
            log.Info("C# HTTP trigger function processed a request.");

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

В версии 4.x шаблон триггера HTTP выглядит следующим образом:

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

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

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

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

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Чтобы обновить проект до версии 4.x службы "Функции Azure":

Обновите локальную установку Azure Functions Core Tools до версии 4.x.
Перейдите к одной из версий Node.js, поддерживаемых в версии 4.x.
Добавьте оба version элемента в extensionBundle host.json, чтобы он выглядел следующим образом:
```
{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}
```
Элемент extensionBundle требуется, так как после версии 1.x привязки сохраняются как внешние пакеты. Дополнительные сведения см. в разделе "Пакеты расширений".
Обновите файл local.settings.json таким образом, чтобы он содержит по крайней мере следующие элементы:
```
{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}
```
Параметр AzureWebJobsStorage может быть эмулятором хранилища Azurite или фактической учетной записью хранения Azure. Дополнительные сведения см. в эмуляторе локального хранилища.

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

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

Самый простой способ — обновить без слотов , а затем повторно опубликовать проект приложения. Вы также можете свести к минимуму время простоя в приложении и упростить откат, обновив слоты.

Обновление без слотов

Самый простой способ обновления до версии 4.x — задать FUNCTIONS_EXTENSION_VERSION параметр ~4 приложения в приложении-функции в Azure. На сайте со слотами необходимо выполнить другую процедуру.

Azure CLI
Azure PowerShell

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Update-AzFunctionAppSetting -AppSetting @{"FUNCTIONS_EXTENSION_VERSION" = "~4"} -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME> -Force

Необходимо также задать другой параметр, который отличается от Windows и Linux.

При запуске в Windows также необходимо включить .NET 6.0, что требуется для среды выполнения версии 4.x.

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

.NET 6 требуется для приложений-функций на любом языке, работающем в Windows.

При запуске в Windows также необходимо включить .NET 6.0, что требуется для среды выполнения версии 4.x.

Set-AzWebApp -NetFrameworkVersion v6.0 -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME>

.NET 6 требуется для приложений-функций на любом языке, работающем в Windows.

Кроме того, может потребоваться обновить linuxFxVersion параметр сайта для конкретной языковой версии. Если у вас уже есть правильное linuxFxVersion значение набора, можно пропустить этот шаг. Дополнительные сведения см. в разделе "Допустимые linuxFxVersion значения".

Приложения PowerShell не поддерживаются в Linux до функций 4.x. Это означает, что вам не нужно обновлять приложение-функцию PowerShell, работающее в Linux.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"

Если выполняется миграция на изолированный рабочий процесс функций .NET, используйте DOTNET-ISOLATED|6.0 либо DOTNET-ISOLATED|7.0 для --linux-fx-versionэтого.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"

Значение --linux-fx-version должно соответствовать целевой версии Java.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"

Значение --linux-fx-version должно соответствовать целевой Node.js версии.

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"

Значение --linux-fx-version должно соответствовать целевой версии PowerShell.

В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

Теперь вы можете повторно опубликовать проект приложения, перенесенный для запуска в версии 4.x.

Обновление с помощью слотов

Использование слотов развертывания — это хороший способ обновить приложение-функцию до среды выполнения версии 4.x из предыдущей версии. С помощью промежуточного слота можно запустить приложение в новой версии среды выполнения в промежуточном слоте и перейти в рабочую среду после проверки. Слоты также позволяют свести к минимуму время простоя во время обновления. Если необходимо свести к минимуму время простоя, выполните действия, описанные в разделе "Минимальное время простоя".

После проверки приложения в обновленном слоте вы можете переключить приложение и новые параметры версии в рабочую среду. Для этого переключения требуется установить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в рабочем слоте. Добавление этого параметра влияет на время простоя, необходимое для обновления.

Стандартное обновление

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

Командлет PowerShell Update-AzFunctionAppSetting в настоящее время не поддерживает слоты. Необходимо использовать Azure CLI или портал Azure.

Используйте следующую команду, чтобы задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в рабочем слоте:
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> 
```
В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов. Эта команда приводит к перезапуску приложения, запущенного в рабочем слоте.
Используйте следующую команду, чтобы также задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS в промежуточном слоте:
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Используйте следующую команду, чтобы изменить FUNCTIONS_EXTENSION_VERSION и обновить промежуточный слот до новой версии среды выполнения:
```
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Для среды выполнения функций версии 4.x требуется .NET 6 в Windows. В Linux приложения .NET также должны обновляться до .NET 6. Используйте следующую команду, чтобы среда выполнения была запущена в .NET 6:
- Windows
- Linux
При запуске в Windows также необходимо включить .NET 6.0, что требуется для среды выполнения версии 4.x.
```
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
```
.NET 6 требуется для приложений-функций на любом языке, работающем в Windows.
Кроме того, может потребоваться обновить linuxFxVersion параметр сайта для конкретной языковой версии. Если у вас уже есть правильное linuxFxVersion значение набора, можно пропустить этот шаг. Дополнительные сведения см. в разделе "Допустимые linuxFxVersion значения".

Приложения PowerShell не поддерживаются в Linux до функций 4.x. Это означает, что вам не нужно обновлять приложение-функцию PowerShell, работающее в Linux.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"
```
Если выполняется миграция на изолированный рабочий процесс функций .NET, используйте DOTNET-ISOLATED|6.0 либо DOTNET-ISOLATED|7.0 для --linux-fx-versionэтого.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"
```
Значение --linux-fx-version должно соответствовать целевой версии Java.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"
```
Значение --linux-fx-version должно соответствовать целевой Node.js версии.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"
```
Значение --linux-fx-version должно соответствовать целевой версии PowerShell.
В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.
Если в проекте кода требуются обновления, чтобы он работал в версии 4.x, разверните эти обновления в промежуточном слоте.
Убедитесь, что приложение-функция работает правильно в обновленной промежуточной среде перед переключением.
Используйте следующую команду, чтобы переключить обновленный промежуточный слот на рабочую среду:
```
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
```

Минимальное обновление простоя

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

Используйте следующую команду, чтобы задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в промежуточном слоте:
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Используйте следующие команды, чтобы переключить слот с новым параметром в рабочую среду и одновременно восстановить параметр версии в промежуточном слоте.
```
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Во период времени между переключением и восстановлением версии среды выполнения в промежуточном слоте в нем могут возникать ошибки. Эта ошибка может произойти, так как WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 при промежуточном выполнении во время переключения параметр удаляется FUNCTIONS_EXTENSION_VERSION в промежуточном режиме. Без параметра версии слот находится в плохом состоянии. Обновление версии в промежуточном слоте сразу после переключения должно вернуть слот обратно в хорошее состояние. При необходимости можно выполнить откат изменений. Однако любой откат переключения также требует непосредственного удаления WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 из рабочей среды перед переключением, чтобы предотвратить те же ошибки в рабочей среде, что и в промежуточной среде. Это изменение в рабочем параметре приведет к перезапуску.
Используйте следующую команду, чтобы снова задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в промежуточном слоте:
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
На этом этапе в обоих слотах установлено WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0.
Используйте следующую команду, чтобы изменить FUNCTIONS_EXTENSION_VERSION и обновить промежуточный слот до новой версии среды выполнения:
```
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Для среды выполнения функций версии 4.x требуется .NET 6 в Windows. В Linux приложения .NET также должны обновляться до .NET 6. Используйте следующую команду, чтобы среда выполнения была запущена в .NET 6:
- Windows
- Linux
При запуске в Windows также необходимо включить .NET 6.0, что требуется для среды выполнения версии 4.x.
```
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
```
.NET 6 требуется для приложений-функций на любом языке, работающем в Windows.
Кроме того, может потребоваться обновить linuxFxVersion параметр сайта для конкретной языковой версии. Если у вас уже есть правильное linuxFxVersion значение набора, можно пропустить этот шаг. Дополнительные сведения см. в разделе "Допустимые linuxFxVersion значения".

Приложения PowerShell не поддерживаются в Linux до функций 4.x. Это означает, что вам не нужно обновлять приложение-функцию PowerShell, работающее в Linux.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"
```
Если выполняется миграция на изолированный рабочий процесс функций .NET, используйте DOTNET-ISOLATED|6.0 либо DOTNET-ISOLATED|7.0 для --linux-fx-versionэтого.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"
```
Значение --linux-fx-version должно соответствовать целевой версии Java.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"
```
Значение --linux-fx-version должно соответствовать целевой Node.js версии.
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"
```
Значение --linux-fx-version должно соответствовать целевой версии PowerShell.
В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.
Если в проекте кода требуются обновления, чтобы он работал в версии 4.x, разверните эти обновления в промежуточном слоте.
Убедитесь, что приложение-функция работает правильно в обновленной промежуточной среде перед переключением.
Используйте следующую команду, чтобы переключить обновленный и предварительно подготовленный промежуточный слот на рабочую среду:
```
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
```

Изменения поведения после версии 1.x

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

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

Начиная с версии 2.x, вам потребуется устанавливать расширения для конкретных триггеров и привязок, которые используются функциями вашего приложения. Единственное исключение — триггеры HTTP и таймера, для которых не требуется расширение. Для получения дополнительной информации ознакомьтесь с разделом Регистрация расширений привязки.

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

Изменения в функциях и возможностях

Некоторые функции были удалены, обновлены или заменены после версии 1.x. В этом разделе подробно описаны изменения, которые вы увидите в более поздних версиях после использования версии 1.x.

В версии 2.x внесены следующие изменения.

Ключи для вызова конечных точек HTTP всегда хранятся в зашифрованном виде в хранилище BLOB-объектов Azure. В версии 1.x эти ключи по умолчанию хранились в хранилище файлов. При переносе приложения с версии 1.x на версию 2.x существующие секреты, которые находятся в Файлы Azure, сбрасываются.
Среда выполнения версии 2.x не имеет встроенной поддержки для поставщиков веб-перехватчиков. Это изменение внесено для повышения производительности. Вы по-прежнему можете использовать HTTP-триггеры как конечные точки для веб-перехватчиков.
Чтобы улучшить мониторинг, панель веб-заданий на портале с параметром AzureWebJobsDashboard замерена Azure Application Insights с параметром APPINSIGHTS_INSTRUMENTATIONKEY. Дополнительные сведения см. в разделе Мониторинг функций Azure.
Все функции в приложении-функции должны использовать один язык. При создании приложения-функции необходимо выбрать для приложения стек среды выполнения. Стек среды выполнения указан значением FUNCTIONS_WORKER_RUNTIME в параметрах приложения. Это требование добавлено для уменьшения занимаемого места и ускорения запуска. При локальной разработке также необходимо включить этот параметр в файл local.settings.json.
По умолчанию для функций в плане службы приложений устанавливается время ожидания 30 минут. Вы можете вручную снять это ограничение, изменив параметр functionTimeout в файле host.json.
Регулирование параллельной обработки HTTP по умолчанию применяется для функций плана потребления, по умолчанию допуская не более 100 одновременных запросов на один экземпляр. Это поведение можно изменить в параметре maxConcurrentRequests файла host.json.
Из-за ограничений .NET Core удалена поддержка функций в виде скриптов F# (файлы .fsx). Скомпилированные функции F# (.fs) по-прежнему поддерживаются.
Для веб-перехватчиков триггера сетки событий формат URL-адреса изменен в соответствии со следующим форматом: https://{app}/runtime/webhooks/{triggerName}.
Имена некоторых предварительно определенных пользовательских метрик были изменены после версии 1.x. Duration был заменен на MaxDurationMs, MinDurationMsи AvgDurationMs. Success Rate также был переименован в Success Rate.

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

Дополнительные сведения о версиях функций

Поделиться через

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

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

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

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

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

Файл проекта

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

файл Program.cs

файл host.json

файле local.settings.json

Изменения имени класса

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

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

Уровни журналов Application Insights и фильтрация

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

Уровни журналов Application Insights и фильтрация

Шаблон триггера HTTP

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

Обновление без слотов

Обновление с помощью слотов

Стандартное обновление

Минимальное обновление простоя

Изменения поведения после версии 1.x

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

Изменения в функциях и возможностях

Рекомендации по Azure Stack Hub

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

Обратная связь

Дополнительные ресурсы