.NET 8 و .NET 9 در 10 نوامبر 2026 EOL می شوند؛ مسیر مهاجرت امن به .NET 10

مایکروسافت تأیید کرده .NET 8 و .NET 9 هر دو در 10 نوامبر 2026 به پایان پشتیبانی می رسند. بعد از آن تاریخ، Security Fix، Servicing Update و پشتیبانی فنی جدید برای این دو نسخه ارائه نمی شود. اگر پروژه Production شما هنوز net8.0 یا net9.0 است، مسئله فقط تغییر TargetFramework نیست؛ SDK، Hosting، Container، Package، EF Core، CI/CD و Rollback هم باید در برنامه مهاجرت دیده شوند.

چرا .NET 8 LTS و .NET 9 STS یک روز EOL می شوند؟

.NET 8 در 14 نوامبر 2023 منتشر شد و طبق سیاست LTS سه سال پشتیبانی دارد؛ این پنجره در 10 نوامبر 2026 بسته می شود. .NET 9 در 12 نوامبر 2024 منتشر شد و مایکروسافت پنجره STS را به 24 ماه افزایش داده است. نتیجه این دو چرخه، پایان پشتیبانی هم زمان در 10 نوامبر است.

LTS بودن نباید با «پشتیبانی بلندمدت نامحدود» اشتباه گرفته شود. نسخه LTS فقط Window مشخص و بلندتری دارد. اگر Lifecycle Runtime در Roadmap فنی ثبت نشود، تیم ممکن است تا نزدیک EOL تصور کند چون روی LTS است نیازی به برنامه ریزی ندارد.

بعد از EOL دقیقاً چه اتفاقی می افتد؟

مایکروسافت صریحاً می گوید برنامه های .NET 8 و .NET 9 بعد از 10 نوامبر همچنان می توانند اجرا شوند. مسئله این است که Security Update جدید، Servicing Fix و Technical Support عادی متوقف می شود. بنابراین خطر اصلی خاموش شدن ناگهانی نیست؛ انباشته شدن ریسکی است که دیگر Patch رسمی دریافت نمی کند.

در محیط Enterprise، Scanner یا Compliance Policy نیز معمولاً Runtime خارج از پشتیبانی را مستقل از CVE فعال به عنوان Finding ثبت می کند. پس Migration هم امنیتی است، هم عملیاتی و هم ممکن است برای Audit ضروری باشد.

چرا .NET 10 مقصد طبیعی این مهاجرت است؟

.NET 10 نسخه LTS فعلی است و مایکروسافت آن را تا نوامبر 2028 در پشتیبانی نگه می دارد. برای سرویس Production که از .NET 8 یا 9 می آید، حرکت به LTS فعلی Window پشتیبانی را دوباره باز می کند و شما را از مهاجرت کوتاه مدت دیگری دور نگه می دارد.

اما انتخاب مقصد باید با Dependencyها نیز سازگار باشد. بعضی Vendor SDKها، APM Agentها، Native Libraryها یا Packageهای قدیمی ممکن است هنوز نسخه مناسب نداشته باشند. قبل از تغییر Solution اصلی، Compatibility Matrix بسازید تا Blocking dependencyها زود کشف شوند.

Inventory قبل از اولین Pull Request

Solutionها را بر اساس Workload دسته بندی کنید: ASP.NET Core API، Worker Service، Console، Desktop، Library، Test Project و ابزارهای Migration. برای هرکدام TargetFramework، RuntimeIdentifier، Publish Mode، Self-contained بودن و Native Dependency را ثبت کنید. Multi-targeting را جدا علامت بزنید چون Consumerهای قدیمی ممکن است محدودیت متفاوت داشته باشند.

بعد محیط اجرا را اضافه کنید: Hosting Bundle روی IIS، Runtime نصب شده روی Linux VM، Base Imageهای sdk و aspnet، Serverless Runtime و Agentهای Monitoring. مهاجرت ناقص معمولاً جایی رخ می دهد که کد net10.0 شده اما Host یا Image هنوز نسخه قبلی را اجرا می کند.

تغییر TargetFramework؛ ساده ترین بخش کار

نمونه رسمی مایکروسافت تغییر TargetFramework به net10.0 را نشان می دهد. این تغییر Compile را وادار می کند ناسازگاری های آشکار را نشان دهد و نقطه شروع خوبی است، اما موفق شدن Build پایان مهاجرت نیست. Behavioral change، serializer، routing، crypto، networking و dependency runtime behavior در Compile دیده نمی شوند.

یک Branch مهاجرت کوچک بسازید و Refactor business را از آن دور نگه دارید. هرچه Diff به تغییر نسخه نزدیک تر باشد، Review و Root Cause Analysis ساده تر می شود. اگر هم زمان معماری را بازنویسی کنید، هر Regression چند مظنون خواهد داشت.

Package، EF Core و Source Generatorها

Dependencyهای مستقیم و Transitive را بررسی کنید. Package ممکن است با net10.0 Compile شود اما روی Reflection، Native Asset، Runtime API یا Source Generator رفتار متفاوتی داشته باشد. Packageهای امنیت، Serialization، Database Provider و APM را High-risk در نظر بگیرید.

برای EF Core، Provider دیتابیس، Query generation، Migration Snapshot و رفتار Tracking را تست کنید. Runtime upgrade زمان مناسبی برای Schema Migration بزرگ نیست مگر الزام مستقیم وجود داشته باشد. جدا نگه داشتن Database Change از Runtime Change، Rollback را بسیار ساده تر می کند.

Container و Hosting؛ جایی که مهاجرت ها نیمه کاره می مانند

اگر Dockerfile شما از mcr.microsoft.com/dotnet/aspnet:8.0 یا 9.0 استفاده می کند، تغییر TargetFramework به net10.0 کافی نیست. SDK Image در Build Stage و Runtime Image در Final Stage هر دو باید بررسی شوند. Image نهایی را با Digest ثبت و Vulnerability Scan کنید.

برای IIS و VM نیز Hosting Bundle و Runtime نصب شده باید به نسخه پشتیبانی شده برسد. در Self-contained Deployment، Runtime داخل Artifact بسته بندی می شود؛ Patch کردن Host به تنهایی نسخه اپلیکیشن را عوض نمی کند. این تفاوت باید در Inventory مشخص باشد.

Test Matrix برای مهاجرت به .NET 10

Unit Test لایه اول است. Integration Test برای Routing، Authentication، Authorization، JSON Serialization، Database Query، Background Service، HTTP Client و File/Stream path بسازید. اگر Reflection، NativeAOT، dynamic code یا Source Generator دارید، سناریوی مخصوص آن ها را جدا کنید.

Performance Baseline را قبل از Upgrade ذخیره کنید: p95/p99 latency، allocation، GC، startup و throughput. هدف اثبات سریع تر بودن .NET 10 نیست؛ هدف این است که Regression workload خودتان را قبل از Rollout سراسری پیدا کنید.

CI/CD و SDK Pinning

اگر global.json دارید، SDK آن را آگاهانه ارتقا دهید. Runnerهای CI، Build container و Developer workstation باید نسخه سازگار داشته باشند. «روی سیستم من Build می شود» وقتی CI هنوز SDK قبلی دارد، Migration را متوقف می کند و ممکن است تیم را به حذف Pinning و ساخت Build غیرقابل تکرار هل دهد.

نسخه SDK و Runtime را در Build metadata ثبت کنید. Artifact باید قابل ردیابی باشد تا بعداً بدانید کدام commit با کدام SDK ساخته شده است. این اطلاعات در Incident پس از Upgrade بسیار ارزشمند است.

Rollout بدون Big Bang

در معماری چند سرویس، API Contract را ثابت نگه دارید تا سرویس net10.0 بتواند مدتی کنار net8.0 یا net9.0 کار کند. از سرویس کم ریسک آغاز کنید، Telemetry نسخه Runtime را Tag کنید و Canary Deployment داشته باشید. بعد از سلامت Canary، گروه بعدی را مهاجرت دهید.

Rollback باید Artifact قبلی باشد، نه Rebuild از Branch قدیمی. اگر Schema database را هم زمان تغییر نداده باشید، بازگشت ساده تر است. این یکی از مهم ترین دلایل جداسازی Runtime Upgrade از Feature و Migration داده است.

Visual Studio و محیط توسعه چه تغییری می کند؟

مایکروسافت اعلام کرده در یک Servicing Update آینده Visual Studio 2022، کامپوننت های .NET 8 و .NET 9 به عنوان out of support علامت می خورند. گزینه remove out of support components نیز برای پاک سازی نسخه های قدیمی وجود دارد. تیم باید مطمئن شود پروژه های قدیمی که هنوز Build می شوند به SDK قبلی وابستگی پنهان ندارند.

Developer environment را بعد از Migration استاندارد کنید: global.json، workloadها، dotnet --info و IDE baseline را مستند کنید. اگر هر توسعه دهنده مجموعه SDK متفاوت داشته باشد، خطاهای Build و Analyzer سخت تر بازتولید می شوند.

اگر نرم افزار .NET متعلق به Vendor است چه کنیم؟

اگر Source در اختیار شما نیست و محصولی از Vendor روی .NET 8 یا 9 اجرا می شود، مایکروسافت توصیه می کند از تولیدکننده نسخه مبتنی بر .NET 10 بخواهید. خودسرانه جایگزین کردن Runtime ممکن است خارج از Support Matrix نرم افزار باشد.

در Procurement و قرارداد پشتیبانی، Runtime lifecycle را وارد سؤال های فنی کنید. محصولی که روی Runtime نزدیک EOL تحویل می شود از روز اول بدهی پشتیبانی دارد. تاریخ نسخه بعدی Vendor و مسیر Escalation را قبل از Deadline رسمی بگیرید.

برنامه زمانی پیشنهادی تا 10 نوامبر

فاز اول Inventory و Dependency Review است؛ فاز دوم Build و Test روی .NET 10؛ فاز سوم Pilot و Canary؛ فاز چهارم Rollout سرویس های اصلی و فاز آخر Cleanup نسخه های قدیمی. برای سیستم های حیاتی، هدف پایان Rollout را حداقل چند هفته پیش از EOL قرار دهید تا Buffer واقعی داشته باشید.

اگر تعداد سرویس زیاد است، همه را یکسان صف نکنید. سرویس های Internet-facing، دارای Compliance بالا، Vendor dependency پیچیده یا Rollback ضعیف زودتر شروع شوند. Priority فقط بر اساس اندازه کد نیست.

Breaking Changeها را چگونه بدون غرق شدن در Release Notes مدیریت کنیم؟

فهرست Breaking Changeهای .NET 10 را با کد خودتان تطبیق دهید، نه اینکه صرفاً همه موارد را بخوانید و تیک بزنید. Namespace، API و Packageهایی را که Solution واقعاً استفاده می کند استخراج کنید و هر Breaking Change مرتبط را به یک Test قابل اجرا وصل کنید. اگر تغییر به Authentication مربوط است، Integration Test Login/Token بسازید؛ اگر Serialization است، Golden File یا Contract Test داشته باشید. هدف تبدیل Release Note به Evidence است.

برای Monorepo، یک Compatibility Board کوچک بسازید که ستون های Component، Change، Owner، Test و Status داشته باشد. این کار از دوباره کاری جلوگیری می کند و مشخص می سازد کدام تغییر واقعاً blocker است. بسیاری از تیم ها زمان زیادی روی Changeهایی صرف می کنند که اصلاً به workload آن ها مربوط نیست، در حالی که یک Package قدیمی حیاتی بدون Owner باقی می ماند.

Observability مهاجرت؛ نسخه Runtime را وارد Telemetry کنید

قبل از Canary، نسخه Runtime و Build را به Tagهای Telemetry اضافه کنید تا بتوانید درخواست های net10.0 را از نسخه قبلی جدا فیلتر کنید. Dashboard باید Error Rate، Latency، GC، Memory، Dependency Failure و Business KPI را برای دو cohort کنار هم نشان دهد. بدون این تفکیک، Canary فقط از نظر تعداد Replica کوچک است اما از نظر مشاهده پذیری کور باقی می ماند.

Alertها را نیز بازبینی کنید. Upgrade ممکن است متن Exception، Event ID یا رفتار retry را عوض کند و Rule قدیمی دیگر Signal درست ندهد. یک مهاجرت موفق فقط زمانی نیست که درخواست پاسخ 200 می گیرد؛ Monitoring، Alerting و Runbook نیز باید با Runtime جدید کار کنند.

بعد از مهاجرت چه چیزهایی باید پاک شوند؟

پس از تثبیت .NET 10، SDK و Runtimeهای منقضی را از Build Agent و Serverهایی که دیگر به آن ها نیاز ندارند پاک کنید، Base Image قدیمی را از Pipeline خارج کنید و Exceptionهای موقت Compatibility را ببندید. اگر global.json یا Matrix CI هنوز .NET 8/9 را فقط از روی عادت نگه داشته، Owner مشخص کند آیا مصرف کننده واقعی وجود دارد یا نه.

همچنین تاریخ Review بعدی Lifecycle را ثبت کنید. مهاجرت امسال نباید دوباره در 2028 به یک پروژه اضطراری تبدیل شود. Support Date را وارد Calendar فنی، Dependency Bot یا Governance Dashboard کنید و شش تا نه ماه قبل از EOL بعدی Discovery را آغاز کنید. Lifecycle Management یک فرآیند تکرارشونده است، نه پروژه ای که بعد از Release فراموش شود.

Rollback را قبل از مهاجرت تمرین کنید

Rollback Plan فقط جمله «نسخه قبلی را Deploy می کنیم» نیست. Artifact قبلی باید هنوز در Registry موجود، تنظیمات محیط سازگار و Database Schema قابل استفاده باشد. در Staging یک بار Rollback واقعی را اجرا کنید و زمان آن را اندازه بگیرید. اگر بازگشت نیازمند Build مجدد، تغییر دستی چند سرور یا بازیابی Backup است، هنوز Rollback سریع ندارید.

در سرویس هایی که چند Instance دارند، Rolling back بخشی از Replicaها می تواند برای تشخیص Regression مفید باشد، به شرط آنکه Contract بین نسخه ها سازگار باشد. Runbook باید Trigger بازگشت، تصمیم گیرنده و معیار سلامت بعد از Rollback را صریح بنویسد تا در Incident بحث درباره مسئولیت زمان را مصرف نکند.

نمونه یا الگوی عملی

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

این تغییر رسمی نقطه شروع است. پس از آن SDK، Runtime/Hosting، Container Image و Packageهای سازگار را ارتقا دهید و Test Matrix را اجرا کنید.

پرسش های متداول

آیا .NET 8 بعد از 10 نوامبر 2026 از کار می افتد؟

خیر. برنامه ها می توانند اجرا شوند، اما Security Update و پشتیبانی فنی جدید دریافت نمی کنند.

چرا .NET 8 LTS و .NET 9 STS یک تاریخ EOL دارند؟

پنجره سه ساله .NET 8 و سیاست 24ماهه STS برای .NET 9 هر دو به 10 نوامبر 2026 می رسند.

آیا تغییر TargetFramework به net10.0 کافی است؟

خیر. SDK، Runtime/Hosting، Container، Package و CI/CD نیز باید بررسی و ارتقا داده شوند.

آیا .NET 10 برای Production مناسب است؟

بله؛ .NET 10 نسخه LTS است و مایکروسافت آن را تا نوامبر 2028 پشتیبانی می کند.

اگر Vendor هنوز نسخه .NET 10 نداده باشد چه کنیم؟

از Vendor برنامه Upgrade و Support رسمی بخواهید و ریسک استفاده از Runtime EOL را مستند کنید.

بهترین زمان شروع مهاجرت چه موقع است؟

پیش از نزدیک شدن به Deadline؛ برای سرویس حساس هدف داخلی چند هفته زودتر از 10 نوامبر تعیین کنید.

منابع رسمی

• اعلامیه رسمی پایان پشتیبانی .NET 8 و .NET 9 — تاریخ EOL، اثر پس از EOL، Visual Studio و توصیه مهاجرت به .NET 10
• سیاست رسمی پشتیبانی .NET — مرجع چرخه LTS/STS و نسخه های Supported
• راهنمای رسمی Upgrade نسخه .NET — مرجع عملی به روزرسانی پروژه و محیط