ترحيل التطبيقات من دالات Azure version 1.x إلى الإصدار 4.x

هام

Go غير مدعوم في الإصدار 1.x من وقت تشغيل دالات Azure، لذلك لا يوجد مسار ترحيل خاص ب Go. لإنشاء تطبيق وظيفة Go من الدرجة الأولى على الإصدار 4.x، راجع بدء Go السريع.

هام

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 أعلاه.

هام

انتهى الدعم للإصدار 1.x من وقت تشغيل دالات Azure في 14 سبتمبر 2026. قم بترحيل تطبيقاتك إلى الإصدار 4.x باتباع التعليمات في هذا المقال. للاطلاع على سلوك وموارد مرجعية في وقت التشغيل التاريخي 1.x، راجع مرجع وقت التشغيل 1.x القديم.

ترشدك هذه المقالة خلال عملية ترحيل تطبيق الوظائف بأمان للتشغيل على الإصدار 4.x من وقت تشغيل الوظائف. نظرا لأن إرشادات ترحيل المشروع تعتمد على اللغة، فتأكد من اختيار لغة التطوير من المحدد في أعلى المقالة.

إذا كنت تستخدم الإصدار 1.x من وقت التشغيل في Azure Stack Hub، راجع ><اعتبارات Azure Stack Hub أولا.

تحديد تطبيقات الوظائف المراد ترحيلها

شغل السكريبت التالي ل PowerShell في Azure Cloud Shell لإنشاء قائمة بتطبيقات الوظائف في اشتراكك التي تستهدف حاليا الإصدار 1.x:

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     $AppSettings = Get-AzFunctionAppSetting -Name $App.Name -ResourceGroupName $App.ResourceGroupName
     if ($AppSettings.FUNCTIONS_EXTENSION_VERSION -like '*1*')
     {
          $AppInfo.Add($App.Name, $AppSettings.FUNCTIONS_EXTENSION_VERSION)
     }
}

$AppInfo

إذا كنت تعمل خارج Cloud Shell، يجب عليك أولا تعيين الاشتراك النشط:

$Subscription = '<SUBSCRIPTION_ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

في هذا المثال، استبدل '<SUBSCRIPTION_ID>' بمعرف اشتراكك.

اختر النسخة المستهدفة .NET

في الإصدار 1.x من وقت تشغيل الوظائف، يستهدف تطبيق وظائف C# الخاص بك .NET Framework.

عندما تقوم بترحيل تطبيق الوظائف الخاص بك، لديك فرصة لاختيار النسخة المستهدفة من .NET. يمكنك تحديث مشروع C# الخاص بك إلى أحد الإصدارات التالية من .NET التي تدعمها Functions الإصدار 4.x:

نسخة .NET .NET سياسة الدعم الرسمية نوع الإصدار نموذجمعالجة الوظائف 1,2
.NET 10 LTS (نهاية الدعم في 14 نوفمبر 2028) نموذج عامل معزول
.NET 9 STS (نهاية الدعم 10 نوفمبر 2026)3 نموذج عامل معزول
.نت 8 LTS (نهاية الدعم في 10 نوفمبر 2026) نموذج عامل معزول،
النموذجقيد المعالجة 2
إطار .NET 4.8 راجع النهج نموذج عامل معزول

1 يدعم نموذج العامل المعزول إصدارات الدعم طويل الأمد (LTS) والدعم القياسي (STS) من .NET، بالإضافة إلى إطار .NET. يدعم نموذج in-process فقط إصدارات LTS من .NET، وينتهي ب .NET 8. للحصول على مقارنة كاملة بين الميزات والوظائف بين النموذجين، انظر الاختلافات بين عمليات العامل أثناء العملية ومعزولة .NET دالات Azure.

2 ينتهي الدعم للنموذج قيد المعالجة في 10 نوفمبر 2026. لمزيد من المعلومات، راجع إعلان الدعم هذا. للحصول على الدعم الكامل المستمر، يجب ترحيل تطبيقاتك إلى نموذج العامل المعزول.

3 .NET كان لدى 9 سابقا تاريخ نهاية دعم متوقع في 12 مايو 2026. خلال نافذة خدمة .NET 9، مدد فريق .NET دعم إصدارات STS إلى 24 شهرا، بدءا من .NET 9. لمزيد من المعلومات، راجع منشور المدونة.

تلميح

ما لم يكن تطبيقك يعتمد على مكتبة أو واجهة برمجة تطبيقات متاحة فقط لإطار .NET، قم بالتحديث إلى .NET 10 على نموذج العامل المعزول. تستهدف العديد من التطبيقات في الإصدار 1.x إطار عمل .NET فقط لأن هذا الخيار كان متاحا عند إنشائها. إذا لم يكن تطبيقك بحاجة للبقاء على إطار .NET بسبب الاعتماد، استهدف .NET 10، وهو إصدار الدعم طويل الأمد الحالي (LTS).

على الرغم من أنه يمكنك اختيار نموذج أثناء العملية، إلا أن هذا النهج غير موصى به إذا كان بإمكانك تجنبه. ينتهي الدعم لنموذج العمل في 10 نوفمبر 2026، لذا عليك الانتقال إلى نموذج العامل المعزول قبل ذلك. ترحيل النماذج أثناء الانتقال إلى الإصدار 4.x يقلل من إجمالي الجهد المطلوب، ويمنح نموذج العامل المعزول تطبيقك مزايا إضافية، بما في ذلك القدرة على استهداف الإصدارات المستقبلية من .NET بسهولة أكبر. إذا كنت تنتقل إلى نموذج العامل المعزول، فإن مساعد الترقية .NET يمكنه أيضا التعامل مع العديد من التغييرات اللازمة في الكود نيابة عنك.

تستهدف أمثلة نماذج العمال المعزولة في هذا الدليل .NET 10. تنطبق أمثلة .NET 8 فقط على النموذج قيد العملية.

التجهيز للترحيل

إذا لم تكن قد فعلت ذلك بعد، حدد قائمة التطبيقات التي تحتاج إلى ترحيلها في اشتراكك الحالي على Azure باستخدام Azure PowerShell.

قبل ترحيل تطبيق إلى الإصدار 4.x من وقت تشغيل الوظائف، يجب عليك القيام بالمهام التالية:

  1. راجع قائمة تغييرات السلوك بعد الإصدار 1.x. يمكن أن يؤثر الترحيل من الإصدار 1.x إلى الإصدار 4.x أيضا على الروابط.
  2. أكمل الخطوات الواردة في ترحيل مشروعك المحلي لترحيل مشروعك المحلي إلى الإصدار 4.x.
  3. بعد ترحيل مشروعك، اختبر التطبيق بالكامل محليا باستخدام الإصدار 4.x من دالات Azure Core Tools.
  4. قم بتحديث تطبيق الوظائف في Azure إلى النسخة الجديدة. إذا كنت بحاجة لتقليل وقت التوقف، فكر في استخدام فتحة stageing لاختبار والتحقق من التطبيق المنتقل في Azure على النسخة الجديدة من وقت التشغيل. ومن ثَم يمكنك نشر تطبيقك مع إعدادات الإصدار المحدثة إلى فتحة الإنتاج. لمزيد من المعلومات، راجع التحديث باستخدام الفتحات.
  5. انشر مشروعك الذي تم ترحيله إلى تطبيق الوظائف المحدث.

عندما تستخدم Visual Studio لنشر مشروع الإصدار 4.x على تطبيق وظائف موجود بنسخة أقل، يطلب منك السماح ل Visual Studio بتحديث تطبيق الوظائف إلى الإصدار 4.x أثناء النشر. يستخدم هذا التحديث نفس العملية المحددة في التحديث بدون فتحات.

ترحيل مشروعك المحلي

القسم التالي يصف التحديثات التي يجب عليك إجراؤها على ملفات مشروع C# الخاصة بك لتتمكن من العمل على أحد الإصدارات المدعومة من .NET في إصدار Functions 4.x. التحديثات المعروضة هي التحديثات الشائعة لمعظم المشاريع. قد تتطلب التعليمات البرمجية للمشروع تحديثات غير مذكورة في هذه المقالة، خاصة عند استخدام حزم NuGet المخصصة.

يتطلب ترحيل تطبيق وظائف C# من الإصدار 1.x إلى الإصدار 4.x من وقت تشغيل الوظائف إجراء تغييرات على التعليمات البرمجية للمشروع. العديد من هذه التغييرات ناتجة عن تغييرات في لغة C# وواجهات برمجة التطبيقات .NET.

اختر التبويب الذي يطابق النسخة المستهدفة من .NET ونموذج العملية المطلوب (عملية العامل أثناء العملية أو معزولة).

تلميح

إذا كنت تنتقل إلى نسخة LTS أو STS من .NET باستخدام نموذج العامل المعزول، يمكن استخدام مساعد الترقية .NET لإجراء العديد من التغييرات المذكورة تلقائيا في الأقسام التالية.

ملف Project

المثال التالي هو .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 هذا لتشغيله في Functions الإصدار 4.x:

تفترض هذه الخطوات مشروع C# محلي؛ إذا كان تطبيقك يستخدم بدلا من ذلك برنامج C# النصي (ملفات.csx )، فيجب عليك التحويل إلى نموذج المشروع قبل المتابعة .

التغييرات التالية مطلوبة في ملف مشروع .csproj XML:

  1. اضبط السمة Sdk على العنصر Project إلى Azure.Functions.Sdk/1.0.0.

  2. تعيين قيمة PropertyGroup. TargetFramework إلى net10.0.

  3. في ItemGroup. PackageReference قم بإدراج، واستبدال مرجع الحزمة إلى Microsoft.NET.Sdk.Functions بالمراجع التالية. احتفظ بالحزمة Microsoft.Azure.Functions.Worker كمرجع صريح:

    <FrameworkReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.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.*. ستستبدل هذه الحزم في خطوة لاحقة.

  4. أضف الجديد ItemGroupالتالي:

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

بعد إجراء هذه التغييرات، يجب أن يبدو مشروعك المحدث مثل المثال التالي:

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.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>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

تغييرات الحزمة ومساحة الاسم

استنادا إلى النموذج الذي تقوم بالترحيل إليه، قد تحتاج إلى تحديث أو تغيير الحزم التي يشير إليها التطبيق الخاص بك. عند اعتماد الحزم الهدف، تحتاج بعد ذلك إلى تحديث مساحة الاسم لاستخدام عبارات وبعض الأنواع التي تشير إليها. يمكنك مشاهدة تأثير تغييرات مساحة الاسم هذه على using العبارات في أمثلة قالب مشغل HTTP لاحقا في هذه المقالة.

إذا لم تفعل ذلك بعد، قم بتحديث مشروعك ليستخدم أحدث الإصدارات المستقرة من:

استنادا إلى المشغلات والروابط التي يستخدمها تطبيقك، قد يحتاج تطبيقك إلى الرجوع إلى مجموعة مختلفة من الحزم. يعرض الجدول التالي الاستبدالات لبعض الملحقات الأكثر استخداما:

السيناريو التغييرات التي تم إجراؤها على مراجع الحزمة
مشغل المؤقت إضافة
Microsoft.Azure. Functions.Worker.Extensions.Timer
روابط التخزين الاستبدال
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
روابط Service Bus استبدال المراجع ب
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 Service استبدال المراجع ب
Microsoft.Azure.WebJobs.Extensions.SignalRService
مع أحدث إصدار من
Microsoft.Azure. Functions.Worker.Extensions.SignalRService
Durable Functions استبدال المراجع ب
Microsoft.Azure.WebJobs.Extensions.DurableTask
مع أحدث إصدار من
Microsoft.Azure. Functions.Worker.Extensions.DurableTask
Durable Functions
(موفر تخزين SQL)		 استبدال المراجع ب
Microsoft.DurableTask.SqlServer.AzureFunctions
مع أحدث إصدار من
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(موفر تخزين 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 الملف أيضا. تأكد من قراءة وثائق كل ملحق تستخدمه. على سبيل المثال، تمديد Service Bus يحتوي على تغييرات متقطعة في البنية بين الإصدارين 4.x و5.x. لمزيد من المعلومات، انظر ناقل خدمة Azure الروابط ل دالات Azure.

يجب ألا يشير تطبيق نموذج العامل المعزول إلى أي حزم في Microsoft.Azure.WebJobs.* أو Microsoft.Azure.Functions.Extensions. إذا كان لديك أي مراجع متبقية لهذه، يجب إزالتها.

تلميح

قد يعتمد تطبيقك أيضا على أنواع Azure SDK، إما كجزء من المحفزات والربط أو كاعتماد مستقل. يجب عليك اغتنم هذه الفرصة لتحديث هذه أيضا. تعمل أحدث إصدارات إضافات الدوال مع أحدث إصدارات Azure SDK ل .NET، ومعظم الحزم لها هي الشكل Azure.*.

يتم دعم روابط Notification Hubs وMobile Apps فقط في الإصدار 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 باستخدام Application Insights SDK. للحصول على تكوين رؤى التطبيقات المعتمدة على OpenTelemetry الموضح في دليل نموذج العامل المعزول، انظر Application Insights. في Program.cs، يجب عليك أيضا تكوين أي تصفية سجل يجب أن تنطبق على السجلات القادمة من التعليمات البرمجية في مشروعك. في نموذج العامل المعزول، يتحكم ملف host.json فقط في الأحداث المنبعثة من وقت تشغيل مضيف الوظائف. إذا لم تقم بتكوين قواعد التصفية في Program.cs، فقد ترى اختلافات في مستويات السجل الموجودة لفئات مختلفة في بيانات تتبع الاستخدام.

على الرغم من أنه يمكنك تسجيل مصادر التكوين المخصصة كجزء من HostBuilder، فإن هذه تنطبق بالمثل فقط على التعليمات البرمجية في مشروعك. تحتاج المنصة أيضا إلى تكوين الزناد والربط، ويجب توفير ذلك من خلال ميزات application settings، Key Vault references، أو ميزات App Configuration references.

بعد نقل كل شيء من أي موجود FunctionsStartup إلى ملف Program.cs ، يمكنك حذف السمة FunctionsStartup والفئة التي تم تطبيقها عليها.

ملف host.json

الإعدادات في ملف host.json تنطبق على مستوى تطبيق الوظائف، محليا وعلى Azure. في الإصدار 1.x، يكون ملف host.json فارغا أو يحتوي على بعض الإعدادات التي تنطبق على جميع الوظائف في تطبيق الوظائف. لمزيد من المعلومات، راجع Host.json v1. إذا كان ملف host.json يحتوي على قيم إعداد، فراجع تنسيق host.json v2 لأي تغييرات.

للتشغيل على الإصدار 4.x، يجب إضافة "version": "2.0" إلى ملف host.json. يجب عليك أيضا التفكير في الإضافة logging إلى التكوين الخاص بك، كما في الأمثلة التالية:

{
    "version": "2.0",
    "telemetryMode": "OpenTelemetry"
}

host.json يتحكم الملف فقط في التسجيل من وقت تشغيل مضيف الوظائف، وفي نموذج العامل المعزول، تأتي بعض هذه السجلات من التطبيق الخاص بك مباشرة، مما يمنحك المزيد من التحكم. راجع إدارة مستويات السجل في نموذج العامل المعزول للحصول على تفاصيل حول كيفية تصفية هذه السجلات.

الملف 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".

تغييرات اسم الفئة

غيرت بعض الفئات الرئيسية الأسماء بين الإصدار 1.x والإصدار 4.x. هذه التغييرات ناتجة إما عن تغييرات في واجهات برمجة تطبيقات .NET أو بسبب اختلافات بين عملية العامل الداخل والعملية المعزولة. يشير الجدول التالي إلى فئات .NET الرئيسية المستخدمة من قبل الدوال والتي قد تتغير عند الترحيل:

الإصدار 1.x .NET 10
FunctionName (سمة) Function (سمة)
TraceWriter ILogger<T>، ILogger
HttpRequestMessage HttpRequestData, HttpRequest (مع تكامل ASP.NET Core)
HttpResponseMessage HttpResponseData, IActionResult (مع تكامل ASP.NET Core)

قد تكون هناك أيضا اختلافات في اسم الفئة في الروابط. لمزيد من المعلومات، راجع المقالات المرجعية للروابط المحددة.

تغييرات أخرى في التعليمات البرمجية

يسلط هذا القسم الضوء على تغييرات التعليمات البرمجية الأخرى التي يجب مراعاتها أثناء العمل من خلال الترحيل. هذه التغييرات غير مطلوبة من قبل جميع التطبيقات، ولكن يجب تقييم ما إذا كانت هناك أي تغييرات ذات صلة بسيناريوهاتك. تأكد من التحقق من تغييرات السلوك بعد الإصدار 1.x للحصول على تغييرات إضافية قد تحتاج إلى إجراءها على مشروعك.

تسلسل JSON

بشكل افتراضي، يستخدم نموذج العامل المعزول System.Text.Json لتسلسل JSON. لتخصيص خيارات التسلسل أو التحول إلى JSON.NET (Newtonsoft.Json)، انظر تخصيص تسلسل JSON.

نظرا لأن النموذج قيد العملية استخدم Newtonsoft.Json، تحقق أيضا من سمات التسلسل على أي أنواع ترتبط بها وظائفك. System.Text.Json يتجاهل سمات مثل [JsonProperty] و [JsonIgnore] من Newtonsoft.Json. يربط الخاصية المتأثرة بقيمتها الافتراضية دون الإبلاغ عن خطأ. إما استبدالها بنظيراتها System.Text.Json ، مثل [JsonPropertyName]، أو تكوين Newtonsoft.Json للطبقة التي تتعامل مع الحمولة.

مستويات سجل Application Insights والتصفية

يمكن إرسال السجلات إلى Application Insights من كل من وقت تشغيل مضيف الوظائف والرمز في مشروعك. يسمح لك host.json بتكوين قواعد لتسجيل المضيف، ولكن للتحكم في السجلات القادمة من التعليمات البرمجية الخاصة بك، تحتاج إلى تكوين قواعد التصفية كجزء من Program.cs. راجع إدارة مستويات السجل في نموذج العامل المعزول للحصول على تفاصيل حول كيفية تصفية هذه السجلات.

قالب مشغل 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"]}!");
        }
    }
}

لتحديث مشروعك إلى دالات Azure 4.x:

  1. قم بتحديث التثبيت المحلي ل دالات Azure Core Tools إلى الإصدار 4.x.

  2. انتقل إلى أحد إصدارات Node.js المدعومة في الإصدار 4.x.

  3. أضف كلا من version و extensionBundle إلى host.json، بحيث يبدو مثل المثال التالي:

    {
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

    extensionBundle العنصر مطلوب لأنه بعد الإصدار 1.x، يتم الاحتفاظ بالروابط كحزم خارجية. لمزيد من المعلومات، راجع حزم الملحقات.

  4. قم بتحديث ملف local.settings.json بحيث يحتوي على العناصر التالية على الأقل:

    {
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}

    إعداد AzureWebJobsStorage يمكن أن يكون إما محاكي تخزين Azurite أو حساب تخزين Azure فعلي. لمزيد من المعلومات، راجع محاكي التخزين المحلي.

تحديث تطبيق الوظائف الخاص بك في Azure

تحتاج إلى تحديث وقت تشغيل مضيف تطبيق الوظائف في Azure إلى الإصدار 4.x قبل نشر مشروعك المنتقل. يتم التحكم في إصدار وقت التشغيل المستخدم من قبل مضيف الوظائف بواسطة FUNCTIONS_EXTENSION_VERSION إعداد التطبيق، ولكن في بعض الحالات يجب أيضا تحديث الإعدادات الأخرى. يتطلب كل من تغييرات التعليمات البرمجية والتغييرات في إعدادات التطبيق إعادة تشغيل تطبيق الوظائف.

أسهل طريقة هي التحديث بدون فتحات ثم إعادة نشر مشروع التطبيق الخاص بك. يمكنك أيضا تقليل وقت التعطل في تطبيقك وتبسيط العودة إلى الحالة السابقة عن طريق التحديث باستخدام الفتحات.

التحديث بدون فتحات

أبسط طريقة للتحديث إلى v4.x هي ضبط إعداد التطبيق FUNCTIONS_EXTENSION_VERSION على ~4 في تطبيق الوظائف الخاص بك في عام Azure. يجب اتباع إجراء مختلف على موقع به فتحات.

  • واجهة سطر الأوامر Azure (Azure CLI)
  • Azure PowerShell 
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

يجب عليك أيضا تعيين إعداد آخر، وهو يختلف بين Windows وLinux.

عند التشغيل على Windows، تحتاج أيضا إلى تفعيل .NET 8.0، وهو مطلوب في الإصدار 4.x من وقت التشغيل.

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

.NET 8.0 مطلوب لتطبيقات الوظائف بأي لغة تعمل على Windows.

في هذا المثال، استبدل <APP_NAME> باسم تطبيق الوظائف واسم <RESOURCE_GROUP_NAME> مجموعة الموارد.

يمكنك الآن إعادة نشر مشروع التطبيق الذي تم ترحيله للتشغيل على الإصدار 4.x.

التحديث باستخدام الفتحات

يعد استخدام فتحات النشر طريقة جيدة لتحديث تطبيق الوظائف إلى وقت تشغيل v4.x من إصدار سابق. باستخدام فتحة التقسيم المرحلي، يمكنك تشغيل تطبيقك على إصدار وقت التشغيل الجديد في فتحة التقسيم المرحلي والتبديل إلى الإنتاج بعد التحقق. توفر الفتحات أيضا طريقة لتقليل وقت التعطل أثناء التحديث. إذا كنت بحاجة إلى تقليل وقت التعطل، فاتبع الخطوات الواردة في الحد الأدنى لتحديث وقت التعطل.

بعد التحقق من تطبيقك في الفتحة المحدثة، يمكنك تبديل التطبيق وإعدادات الإصدار الجديد إلى الإنتاج. يتطلب هذا التبديل إعداد WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 في فتحة الإنتاج. تؤثر كيفية إضافة هذا الإعداد على مقدار وقت التعطل المطلوب للتحديث.

تحديث قياسي

إذا كان تطبيق الوظائف الممكنة للفتحة يمكنه معالجة وقت تعطل إعادة التشغيل الكاملة، يمكنك تحديث WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS الإعداد مباشرةً في فتحة الإنتاج. نظراً لأن تغيير هذا الإعداد مباشرةً في فتحة الإنتاج يؤدي إلى إعادة التشغيل التي تؤثر على التوفر، ففكر في إجراء هذا التغيير في وقت انخفاض نسبة استخدام الشبكة. يمكنك بعد ذلك التبديل في الإصدار المحدث من فتحة التقسيم المرحلي.

لا يدعم PowerShell cmdlet Update-AzFunctionAppSetting حالياً الفتحات. يجب عليك استخدام Azure CLI أو بوابة Azure.

  1. استخدم الأمر التالي لتعيينه 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> مجموعة الموارد. يؤدي هذا الأمر إلى إعادة تشغيل التطبيق قيد التشغيل في فتحة الإنتاج.

  2. استخدم الأمر التالي لتعيين 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>

  3. استخدم الأمر التالي لتغيير FUNCTIONS_EXTENSION_VERSION وتحديث فتحة التقسيم المرحلي إلى إصدار وقت التشغيل الجديد:

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

  4. يتطلب الإصدار 4.x من وقت تشغيل الوظائف .NET 8.0 في Windows. على لينكس، يجب على تطبيقات .NET أيضا التحديث إلى .NET 8.0. استخدم الأمر التالي حتى يتمكن وقت التشغيل من العمل على .NET 8.0:

    عند التشغيل على Windows، تحتاج أيضا إلى تفعيل .NET 8.0، وهو مطلوب في الإصدار 4.x من وقت التشغيل.

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

    تطبيقات الوظائف بأي لغة تعمل على Windows تتطلب .NET 8.0.

    في هذا المثال، استبدل <APP_NAME> باسم تطبيق الوظائف واسم <RESOURCE_GROUP_NAME> مجموعة الموارد.

  5. إذا كان مشروع التعليمات البرمجية يتطلب أي تحديثات لتشغيله على الإصدار 4.x، فقم بنشر هذه التحديثات إلى فتحة التقسيم المرحلي الآن.

  6. تأكد من أن تطبيق الوظائف يعمل بشكل صحيح في بيئة التقسيم المرحلي المحدثة قبل التبديل.

  7. استخدم الأمر التالي لتبديل فتحة التقسيم المرحلي المحدثة إلى الإنتاج:

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

الحد الأدنى لتحديث وقت التعطل

لتقليل وقت التعطل في تطبيق الإنتاج، يمكنك تبديل الإعداد WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS من فتحة التقسيم المرحلي إلى الإنتاج. بعد ذلك، يمكنك التبديل في الإصدار المحدث من فتحة تشغيل مرحلي مسبقة البدء.

  1. استخدم الأمر التالي لتعيين 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>

  2. استخدم الأوامر التالية للتبديل بين الفتحة والإعداد الجديد في الإنتاج، وفي الوقت نفسه استعادة إعداد الإصدار في فتحة التقسيم المرحلي.

    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 مباشرةً من الإنتاج قبل التبديل مرة أخرى لمنع حدوث نفس الأخطاء في الإنتاج التي تظهر في التقسيم المرحلي. سيؤدي هذا التغيير في إعداد الإنتاج بعد ذلك إلى إعادة تشغيل.

  3. استخدم الأمر التالي لتعيين 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 تعيين كلا الفتحتين.

  4. استخدم الأمر التالي لتغيير FUNCTIONS_EXTENSION_VERSION وتحديث فتحة التقسيم المرحلي إلى إصدار وقت التشغيل الجديد:

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

  5. يتطلب الإصدار 4.x من وقت تشغيل الوظائف .NET 8.0 في Windows. على لينكس، يجب على تطبيقات .NET أيضا التحديث إلى .NET 8.0. استخدم الأمر التالي حتى يتمكن وقت التشغيل من العمل على .NET 8.0:

    عند التشغيل على Windows، تحتاج أيضا إلى تفعيل .NET 8.0، وهو مطلوب في الإصدار 4.x من وقت التشغيل.

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

    .NET 8.0 مطلوب لتطبيقات الوظائف بأي لغة تعمل على Windows.

    في هذا المثال، استبدل <APP_NAME> باسم تطبيق الوظائف واسم <RESOURCE_GROUP_NAME> مجموعة الموارد.

  6. إذا كان مشروع التعليمات البرمجية يتطلب أي تحديثات لتشغيله على الإصدار 4.x، فقم بنشر هذه التحديثات إلى فتحة التقسيم المرحلي الآن.

  7. تأكد من أن تطبيق الوظائف يعمل بشكل صحيح في بيئة التقسيم المرحلي المحدثة قبل التبديل.

  8. استخدم الأمر التالي لتبديل فتحة التقسيم المرحلي المحدثة والمقدمة مسبقا إلى الإنتاج:

    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 لـ Event Hub هي الآن eventHubName. راجع جدول الربط الموجود للحصول على ارتباطات الوثائق لكل ربط.

التغييرات في الميزات والوظائف

تمت إزالة بعض الميزات أو تحديثها أو استبدالها بعد الإصدار 1.x. يوضح هذا القسم بالتفصيل التغييرات التي تراها في الإصدارات الأحدث بعد استخدام الإصدار 1.x.

في الإصدار 2.x، تم إجراء التغييرات التالية:

  • مفاتيح استدعاء نقاط نهاية HTTP دائما ما تخزن مشفرة في تخزين Azure Blob. في الإصدار 1.x، كانت المفاتيح تخزن في ملفات Azure بشكل افتراضي. عند نقل تطبيق من الإصدار 1.x إلى الإصدار 2.x، يتم إعادة تعيين الأسرار الموجودة في ملفات Azure.

  • لا يتضمن وقت تشغيل الإصدار 2.x دعمًا مضمنًا لمقدمي الإخطار على الويب. تم إجراء هذا التغيير لتحسين الأداء. لا يزال بإمكانك استخدام مشغلات HTTP كنقاط نهاية للإخطارات على الويب.

  • لتحسين المراقبة، تم استبدال لوحة تحكم WebJobs في البوابة، التي كانت تستخدم إعداد AzureWebJobsDashboard ب Azure Application Insights، الذي يستخدم إعداد APPINSIGHTS_INSTRUMENTATIONKEY. لمزيد من المعلومات، راجع Monitor دالات Azure.

  • يجب أن تشترك جميع الدوال الموجودة في تطبيق الدوال في نفس اللغة. عند إنشاء تطبيق دالة، يجب عليك اختيار مكدس وقت التشغيل للتطبيق. يتم تحديد مكدس وقت التشغيل بواسطة القيمة FUNCTIONS_WORKER_RUNTIME في إعدادات التطبيق. تم إضافة هذا المتطلب لتحسين الموضع ووقت بدء التشغيل. عند التطوير محليًا، يجب أيضًا تضمين هذا الإعداد في الملف local.settings.json.

  • يتم تغيير المهلة الافتراضية للدوال في خطة App Service إلى 30 دقيقة. يمكنك إعادة تغيير المهلة يدويًا إلى غير محدود باستخدام الإعداد functionTimeout في host.json.

  • يتم تنفيذ تقييدات تزامن HTTP بشكل افتراضي لدوال خطة الاستهلاك، بعدد افتراضي يبلغ 100 طلب متزامن لكل مثيل. يمكنك تغيير هذا السلوك في الإعداد maxConcurrentRequests في ملف Host.json.

  • بسبب قيود .NET الأساسية، تم إزالة دعم وظائف سكريبت F# (.fsx files). لا تزال دوال F# (.fs) المحولة برمجيًا مدعومة.

  • تم تغيير تنسيق عنوان URL لخطافات الويب المشغلة لشبكة الأحداث ليتبع هذا النمط:https://{app}/runtime/webhooks/{triggerName}.

  • تم تغيير أسماء بعض المقاييس المخصصة المحددة مسبقا بعد الإصدار 1.x. Duration تم استبدال ب MaxDurationMsو MinDurationMsو AvgDurationMs. Success Rate تمت إعادة تسمية أيضا إلى Success Rate.

اعتبارات ل Azure Stack Hub

App Service على Azure Stack Hub لا تدعم الإصدار 4.x من دالات Azure. عندما تخطط للترحيل من الإصدار 1.x في Azure Stack Hub، يمكنك اختيار أحد الخيارات التالية:

  • انتقل إلى الإصدار 4.x المستضاف في السحابة العامة دالات Azure باستخدام التعليمات الواردة في هذا المقال. بدلا من ترقية تطبيقك الحالي، يمكنك إنشاء تطبيق جديد باستخدام الإصدار 4.x ثم نشر مشروعك المعدل إليه.
  • انتقل إلى WebJobs المستضافة على خطة خدمة التطبيقات في Azure Stack Hub.

الخطوات التالية

تعرف على المزيد حول إصدارات الوظائف

  • Last updated on