.NET-ის ვერსიები, LTS თუ STS და როდის განაახლო

production-ში LTS რელიზი გაუშვი, თუ საწინააღმდეგო მიზეზი არ გაქვს, და განახლება მხარდაჭერის დასრულებამდე დაგეგმე და არა მის შემდეგ. 2026 წლის ოქტომბრის მდგომარეობით ეს ნიშნავს .NET 10-ს, მიმდინარე long-term support რელიზს, რომელიც მხარდაჭერილია 2028 წლის ნოემბრამდე. .NET 8-ის (LTS) და .NET 9-ის (STS) მხარდაჭერა ორივესი 2026 წლის 10 ნოემბერს სრულდება - რამდენიმე კვირაში - ამიტომ ყველაფერი, რაც ჯერ კიდევ რომელიმე მათგანზეა, უნდა გადაადგილდეს. .NET 11 2026 წლის ნოემბერში მოსალოდნელია, როგორც standard-term რელიზი. ეს პოსტი ხსნის მხარდაჭერის მოდელს, რა ხდება რეალურად, როცა ვერსია მხარდაჭერიდან გადის, როგორ გადაიტანო პროექტი ვერსიებს შორის სიურპრიზების გარეშე, და რას აკეთებს global.json და roll-forward-ის პარამეტრები იმაზე, რომელ SDK-სა და runtime-ს იღებ.

რელიზების მოდელი: ერთი მთავარი ვერსია წელიწადში#

Microsoft ყოველ ნოემბერში .NET-ის ახალ მთავარ ვერსიას უშვებს. ლუწნომრიანი რელიზები LTS-ია (long-term support), ხოლო კენტნომრიანი - STS (standard-term support).

STS-ის ფანჯარა ადრე 18 თვე იყო. .NET 9-დან დაწყებული Microsoft-მა ის 24 თვემდე გაზარდა, რის გამოც .NET 9 ახლა იმავე დღეს სრულდება, რომელსაც .NET 8 და არა ექვსი თვით ადრე. STS რელიზი ბეტა არ არის - ის სრულად მხარდაჭერილია, იმავე ყოველთვიურ patch-ებს იღებს და production-ში მას ბევრი გუნდი იყენებს, რომელსაც ფუნქციები წლით ადრე უნდა. გაცვლა ის არის, რომ ორ-სამ წელიწადში ერთხელ კი არა, ყოველწლიურად ანახლებ.

მიმდინარე სასიცოცხლო ციკლი იმ ვერსიებისთვის, რომლებსაც სავარაუდოდ შეხვდები:

Patch-ები Patch Tuesday-ზე გამოდის, ყოველი თვის მეორე სამშაბათს. მხარდაჭერის თარიღი ბოლო patch-ის დღეა; მის შემდეგ ვერსია უსაფრთხოების გამოსწორებებს საერთოდ აღარ იღებს. Microsoft-ის ოფიციალური .NET-ის მხარდაჭერის პოლიტიკის გვერდი ის წყაროა, რომელიც უნდა შეამოწმო, სანამ ამ ცხრილის რომელიმე თარიღზე დაგეგმავ.

რას ნიშნავს მხარდაჭერის დასრულება სინამდვილეში#

მხარდაჭერის დასრულების დღეს არაფერი ითიშება. .NET 8-ზე მყოფი აპლიკაცია 2026 წლის 11 ნოემბერს ზუსტად ისე გაეშვება, როგორც წინა დღეს. რა იცვლება:

• უსაფრთხოების patch-ები აღარ არის. შემდეგი მოწყვლადობა Kestrel-ში, TLS სტეკში, System.Text.Json-ში ან თავად runtime-ში შენს ვერსიაში სამუდამოდ ღია რჩება. ინტერნეტისკენ მიმართული ვებ აპლიკაციისთვის ეს მთელი არგუმენტია.
• კონტეინერის image-ები აღარ განახლდება. mcr.microsoft.com/dotnet/aspnet:8.0 ტეგები pull-ისთვის ხელმისაწვდომი რჩება, მაგრამ მათ ქვეშ არსებული საბაზისო ოპერაციული სისტემის პაკეტებიც აღარ ახლდება.
• ბიბლიოთეკები წინ მიდის. NuGet პაკეტები მომდევნო ერთ-ორ წელიწადში ძველ target-ებს ტოვებს, და ბიბლიოთეკის ის ვერსია, რომელიც შენს წინაშე მდგარ ხარვეზს ასწორებს, შეიძლება შენს framework-ს აღარ უჭერდეს მხარს.
• ჰოსტები და ინსტრუმენტები წინ მიდის. build agent-ები, SDK-ის ინსტალერები და ჰოსტინგის image-ები საბოლოოდ ძველი runtime-ების ტარებას წყვეტს.

პრაქტიკული წესი: LTS რელიზი შემდეგ LTS-თან ერთწლიან გადაფარვას გაძლევს. განაახლე ამ წლის განმავლობაში, როცა ახალ ვერსიას პირველი რამდენიმე patch უკვე აქვს და შენს მიერ გამოყენებული ბიბლიოთეკები დაეწია, და არა ბოლო თვეში.

Target framework, SDK და runtime: სამი სხვადასხვა ვერსია#

განახლების დაბნეულობის უმეტესობა იქიდან მოდის, რომ ამათ ერთ რიცხვად აღიქვამენ.

• Target framework - რის მიმართ კომპილირდება შენი პროექტი, პროექტის ფაილში დაყენებული როგორც <TargetFramework>net10.0</TargetFramework>. ის წყვეტს, რომელი API-ების გამოძახება შეგიძლია და რომელი runtime სჭირდება აპლიკაციას.
• SDK - ინსტრუმენტების ნაკრები, რომელიც პროექტს აშენებს: dotnet build, dotnet publish, კომპილატორები. SDK-ის ვერსიები ასე გამოიყურება: 10.0.100; ასეულების ციფრი feature band-ია (10.0.1xx, 10.0.2xx), ხოლო ბოლო ორი ციფრი - patch.
• Runtime - რაც კომპილირებულ აპლიკაციას უშვებს. ASP.NET Core აპლიკაციებს იმავე მთავარი ვერსიის ASP.NET Core shared runtime სჭირდება, ვერსიებით როგორიცაა 10.0.0, 10.0.1 და ასე შემდეგ.

SDK-ს შეუძლია საკუთარი ვერსიისა და ყველა უფრო ადრეული target framework-ისთვის აშენება, ამიტომ .NET 10 SDK net8.0 პროექტს უპრობლემოდ აშენებს. პირიქით არ მუშაობს: .NET 8 SDK-ს net10.0-ის აშენება არ შეუძლია. runtime უშვებს აპლიკაციებს, რომლებიც მის მთავარ ვერსიას მიზნად ისახავს, და roll-forward-ის პარამეტრებით ზოგჯერ უფრო ახლებსაც.

$ dotnet --list-sdks8.0.415 [/usr/share/dotnet/sdk]10.0.100 [/usr/share/dotnet/sdk]$ dotnet --list-runtimesMicrosoft.AspNetCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]Microsoft.NETCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

შეცდომა, რომელსაც ხალხი ხვდება, როცა runtime და target არ ემთხვევა, შეუცდომლად ამოსაცნობია:

You must install or update .NET to run this application.Framework: 'Microsoft.AspNetCore.App', version '10.0.0' (x64)The following frameworks were found:  8.0.11 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]

ჰოსტინგის აპლიკაციის სერვერზე ხელმისაწვდომი runtime ის არის, რასაც სერვერის image გთავაზობს, ამიტომ სანამ target-ს შეცვლი, გაარკვიე, რომელ SDK-სა და runtime-ს ატარებს. self-contained publish ამას საერთოდ გვერდს უვლის, runtime-ს შენი build-ის გამოტანაში აგზავნის, გაცილებით დიდი deploy-ის ფასად; dotnet publish და runtime-ის პარამეტრები ამ გაცვლას განიხილავს.

SDK-ის დაფიქსირება global.json-ით#

global.json-ის გარეშე dotnet მანქანაზე დაყენებულ უახლეს SDK-ს იყენებს. ლეპტოპზე ჩვეულებრივ ეს გინდა, ხოლო build სერვერზე ზოგჯერ პრობლემაა, სადაც SDK-ის განახლებამ ერთი და იმავე commit-ის ორ build-ს შორის შეიძლება შეცვალოს analyser-ის გაფრთხილებები, ნაგულისხმევი ქცევა ან გენერირებული ფაილების ფორმატი.

{  "sdk": {    "version": "10.0.100",    "rollForward": "latestFeature"  }}

version მინიმალური SDK-ია. rollForward წყვეტს, რამდენად ზემოთ შეუძლია dotnet-ს მისგან წასვლა:

latestFeature გონივრული არჩევანია repository-ების უმეტესობისთვის: build-ები .NET 10 SDK-ებზე რჩება და მაინც იღებს patch-ებსა და feature band-ებს. disable უსაფრთხოდ ჟღერს და build-ს ტეხავს ყველა მანქანაზე, რომელსაც შენზე ახალი patch აქვს. თუ არცერთი დაყენებული SDK ფაილს არ აკმაყოფილებს, შეცდომა ასახელებს ვერსიას, რომელიც უნდოდა - დააყენე ეს SDK ან შეარბილე პოლიტიკა.

global.json მხოლოდ SDK-ზე მოქმედებს. ის არ ცვლის target framework-ს და არ ცვლის, რომელ runtime-ზე მუშაობს აპლიკაცია.

Runtime-ის roll-forward#

framework-dependent აპლიკაცია, რომელიც net10.0-ს მიზნად ისახავს, runtime-ის უმაღლეს დაყენებულ 10.0.x patch-ზე მუშაობს, ავტომატურად. ასე იღებს შენი აპლიკაცია უსაფრთხოების გამოსწორებებს patch-ირებული runtime-იდან ხელახალი build-ის გარეშე, და სწორედ ამიტომ არ უნდა სცადო runtime-ის კონკრეტული patch-ის დაფიქსირება.

minor და major ვერსიებს შორის ქცევას RollForward პროექტის თვისება (ან DOTNET_ROLL_FORWARD გარემოს ცვლადი) აკონტროლებს:

Major net8.0 აპლიკაციას საშუალებას აძლევს გაეშვას მანქანაზე, რომელსაც მხოლოდ .NET 10 runtime აქვს. ჩვეულებრივ მუშაობს, და განახლებას არ ცვლის: მუშაობ runtime-ზე, რომელზეც აპლიკაცია არასოდეს შემოწმებულა, და ორ ვერსიას შორის ყველა breaking change ჩუმად ვრცელდება. გამოიყენე ის საგანგებო სიტუაციაში დროის მოსაგებად და არა პოლიტიკად.

პროექტის განახლება, ნაბიჯ-ნაბიჯ#

.NET 8-დან .NET 10-ზე გადასვლა ვებ აპლიკაციების უმეტესობისთვის მოკლე სამუშაოა, თუ რიგით გააკეთებ:

1. დააყენე ახალი SDK და დაამატე ან განაახლე global.json, რომ repository მისით აშენდეს.
2. შეცვალე target framework ყველა პროექტში: net8.0 net10.0-ზე. ბევრ პროექტიან solution-ში Directory.Build.props, რომელიც TargetFramework-ს ერთხელ აყენებს, ყოველი ფაილის რედაქტირებას გაგარიდებს.
3. განაახლე Microsoft-ის პაკეტები შესაბამის მთავარ ვერსიამდე. პაკეტები, როგორიცაა Microsoft.AspNetCore.Authentication.JwtBearer, Microsoft.EntityFrameworkCore.* და Microsoft.Extensions.*, runtime-თან ერთად ვერსიონირდება; net10.0 აპლიკაციამ მათი 10.x ვერსიები უნდა გამოიყენოს.
4. განაახლე მესამე მხარის პაკეტები, განსაკუთრებით მონაცემთა ბაზის provider-ები. Npgsql, Pomelo MySQL provider და სხვები თითო EF Core-ის მთავარ ვერსიაზე ვერსიას უშვებენ; დაწყებამდე შეამოწმე, რომ შენთვის საჭირო არსებობს.
5. ააშენე ხილული გაფრთხილებებით და წაიკითხე ისინი. ახალი analyser-ები და obsoletion-ები ჯერ გაფრთხილებებად ჩნდება.
6. წაიკითხე breaking change-ების სია ყოველი ვერსიისთვის, რომელსაც გამოტოვებ. Microsoft თითო რელიზზე ერთს აქვეყნებს .NET-ის დოკუმენტაციაში, სფეროების მიხედვით დალაგებულს. 8-დან 10-ზე გადასვლა ნიშნავს 9-ისა და 10-ის ორივე სიის წაკითხვას.
7. გაუშვი ტესტები, შემდეგ აპლიკაცია production-ის მონაცემების ასლზე, და deploy გააკეთე სატესტო სერვერზე production-მდე.

$ dotnet list package --outdated$ dotnet list package --vulnerable --include-transitive

მეორე ბრძანების გაშვება ყოველ პროექტზე ღირს განახლებების მიუხედავად: ის ჩამოთვლის ცნობილი მოწყვლადობების მქონე პაკეტებს, მათ შორის არაპირდაპირ შემოტანილებსაც.

ბოლო ვერსიების ზოგიერთი ცვლილება, რომელიც ხალხს მართლა აბრკოლებს:

• .NET 8-მა Microsoft-ის ASP.NET Core კონტეინერის image-ებში ნაგულისხმევი პორტი 80-დან 8080-ზე შეცვალა და დაამატა ASPNETCORE_HTTP_PORTS, როგორც მისი დაყენების უფრო მარტივი გზა. აპლიკაციებმა, რომლებიც კონტეინერის შიგნით 80 პორტს ეყრდნობოდა, საბაზისო image-ის განახლების შემდეგ პასუხი შეწყვიტეს.
• .NET 9-მა `BinaryFormatter`-ის იმპლემენტაცია ამოიღო - ის runtime-ში გამონაკლისს ისვრის. ძველი ქეშირების ან სესიის კოდი, რომელიც ობიექტებს მისით სერიალიზებდა, მხოლოდ მაშინ ვარდება, როცა ეს კოდის გზა გაეშვება.
• EF Core-ის მთავარი ვერსიები runtime-ს მიჰყვება. EF Core 10-ს .NET 10 სჭირდება, ამიტომ ახალ EF Core-ს ახალი runtime-ის გარეშე ვერ აიღებ, ხოლო უფრო ახალი EF Core ინსტრუმენტით გენერირებული migration-ები გამოყენებამდე უნდა გადაიხედოს. EF Core-ის migration-ები production-ში განიხილავს, როგორ გამოიყენო ისინი უსაფრთხოდ.

განახლების გავრცელება production-ის რისკის გარეშე#

ყველაზე უსაფრთხო განახლება ის არის, რომლის გაუქმებაც წუთში შეგიძლია. განახლება საკუთარ ბრენჩზე დატოვე და ეს ბრენჩი მეორე, პატარა სერვერზე გაუშვი, სანამ ის იმ სერვერს მიუახლოვდება, რომელსაც შენი მომხმარებლები იყენებენ. სატესტო სერვერი, რომელიც გაშვებისას განახლების ბრენჩს pull-ს უკეთებს და production-ის მონაცემთა ბაზის ასლზეა მიმართული, იჭერს ორ ჩავარდნას, რომელსაც unit ტესტები ვერ ამჩნევს: დამოკიდებულებას, რომელიც runtime-ში სხვაგვარად იქცევა, და migration-ს, რომელიც რეალურ მონაცემებზე ნელია ან ცხრილს ბლოკავს. სატესტო სერვერის გაშვება production-ის გვერდით განიხილავს, როგორ შეინარჩუნო ისინი ცალ-ცალკე, ხოლო ASP.NET Core აპლიკაციის deploy GitHub-იდან თავად deploy-ს ფარავს.

production-ზე გადართვამდე გააკეთე მონაცემთა ბაზის backup და დარწმუნდი, რომ წინა build ერთი commit-ის მოშორებითაა. თუ ახალი ვერსია ცუდად იქცევა, target framework-ის commit-ის დაბრუნება და ხელახალი deploy არის rollback; მონაცემთა ბაზის migration, რომელიც უკვე გაეშვა, ის ნაწილია, რომლის დაბრუნებაც ასე მარტივად არ შეიძლება, და ამიტომ სქემის ცვლილებები ცალკე deploy-ით უნდა გავიდეს runtime-ის განახლებამდე ან მის შემდეგ და არა იმავეში.

net8.0 ბიბლიოთეკის multi-target-ზე გადაყვანა კარგი შუალედური ნაბიჯია, როცა მასზე რამდენიმე აპლიკაციაა დამოკიდებული: <TargetFrameworks>net8.0;net10.0</TargetFrameworks> (შენიშნე მრავლობითი) ორივეს აშენებს, და თითოეული აპლიკაცია შესაბამისს იღებს.

LTS თუ STS: რომელი უნდა გაუშვა?#

LTS, თუ აპლიკაციას ეპიზოდურად უვლიან, თუ განახლებებს დამტკიცება სჭირდება, ან თუ გუნდი ერთი ადამიანია, რომელსაც სხვა საქმეებიც აქვს. სამი წლის patch-ები და შემდეგ LTS-თან ერთწლიანი გადაფარვა უფრო ნელ რიტმს ერგება.

STS, თუ განუწყვეტლივ აკეთებ deploy-ს, დამოკიდებულებებს რეგულარულად ანახლებ და ფუნქციები გინდა - განსაკუთრებით წარმადობის გაუმჯობესებები ყოველწლიურად მოდის - თორმეტი თვით ადრე. 24-თვიანი მხარდაჭერით STS რელიზი აღარ არის ის მოკლევადიანი არჩევანი, რაც ადრე იყო, მაგრამ ის მაინც იმავე დროს ან წინა LTS-ზე ადრე სრულდება, ამიტომ ყოველწლიურ განახლებაზე იღებ ვალდებულებას.

რაც არ უნდა გაუშვა, არის ვერსია, რომელიც მხარდაჭერის გარეთაა, ან preview production-ში. Preview-ები და release candidate-ები ყოველი წლის თებერვლიდან ჩნდება; release candidate-ებს Microsoft-ისგან go-live ლიცენზია აქვს, რაც production-ში გამოყენების მხარდაჭერას ნიშნავს, მაგრამ აპლიკაცია, რომელიც ჰოსტინგის სერვერზე preview runtime-ზეა დამოკიდებული, დამოკიდებულია იმაზე, რომ ეს სერვერი მას ატარებს.

C#-ის ენის ვერსიები SDK-ს მიჰყვება: C# 12 .NET 8-თან ერთად გამოვიდა, C# 13 .NET 9-თან, C# 14 .NET 10-თან. ნაგულისხმევი LangVersion ის არის, რომელიც შენს target framework-ს შეესაბამება, ხოლო მისი იმაზე მაღლა დაყენება, ვიდრე target უჭერს მხარს, მხარდაჭერილი არ არის მაშინაც კი, როცა კომპილირდება.

.NET Framework სხვა პროდუქტია#

ბოლო პუნქტი, რომელიც ჰოსტინგისთვის მნიშვნელოვანია: .NET Framework 4.x არ არის .NET. ეს თავდაპირველი, მხოლოდ Windows-ის framework-ია, ჯერ კიდევ მხარდაჭერილი Windows-ის ნაწილად, ჯერ კიდევ უამრავ პროგრამულ უზრუნველყოფას ამუშავებს და Linux-ზე არ მუშაობს. ASP.NET (არა ASP.NET Core) აპლიკაციის, რომელიც .NET Framework 4.8-ზეა, Linux კონტეინერზე deploy საერთოდ შეუძლებელია. მისი გადატანა ნიშნავს ASP.NET Core-ზე პორტირებას .NET 10-ზე, რაც MVC აპლიკაციებისთვის რეალური მიგრაციის პროექტია და არა უბრალოდ target-ის შეცვლა - System.Web თანამედროვე .NET-ში არ არსებობს.

ბიბლიოთეკები, რომლებსაც ორივე სამყაროს მომსახურება სჭირდება, netstandard2.0-ს მიზნად ისახავს, რომლის მოხმარებაც .NET Framework 4.6.1-სა და უფრო ახალს და ყველა თანამედროვე .NET-ს შეუძლია. ახალი ბიბლიოთეკები მხოლოდ თანამედროვე .NET-ისთვის პირდაპირ net8.0-ს ან უფრო ახალს უნდა ისახავდეს მიზნად.

FAQ#

ჯერ კიდევ უსაფრთხოა .NET 8-ის გამოყენება?

2026 წლის 10 ნოემბრამდე ის უსაფრთხოების patch-ებს იღებს, ამიტომ დღეს უსაფრთხოა. ამ თარიღის შემდეგ ის არაფერს იღებს. თუ ახლა .NET 8-ზე ხარ, .NET 10-ზე განახლება უნდა დაიგეგმოს და არა განიხილებოდეს.

გამოვტოვო .NET 11 და დაველოდო .NET 12-ს?

თუ LTS რელიზებს უშვებ, კი: გადადი 10-დან 12-ზე, რომელიც 2027 წლის ნოემბერშია მოსალოდნელი, იმ წლის განმავლობაში, როცა ორივე მხარდაჭერილია. თუ STS რელიზებს უშვებ, აიღე 11, როცა გამოვა და მისი პირველი patch გამოქვეყნდება.

ყოველი ყოველთვიური patch-ისთვის აპლიკაციის ხელახლა აშენება მჭირდება?

framework-dependent აპლიკაციებისთვის არა. აპლიკაცია ავტომატურად გადადის თავისი runtime-ის უახლეს დაყენებულ patch-ზე. self-contained აპლიკაციები საკუთარ runtime-ს ატარებს, ამიტომ თითო patch-ის მისაღებად ხელახალი build და deploy სჭირდება.

შეუძლია .NET 8 აპლიკაციას .NET 10 runtime-ზე მუშაობა?

მხოლოდ RollForward-ით, რომელიც Major-ზე ან LatestMajor-ზეა დაყენებული, და ისიც ახალი runtime-ის breaking change-ების მიმართ რაიმე ტესტირების გარეშე. net10.0-ზე target-ის შეცვლა და ტესტირება სწორი გამოსავალია.

რას აკეთებს global.json, თუ არ მაქვს?

არაფერს, რაც ნიშნავს, რომ პროექტს უახლესი დაყენებული SDK აშენებს. ლოკალურად ეს კარგია, ხოლო build სერვერებზე შეიძლება გადახრა გამოიწვიოს. დაამატე ის rollForward-ით latestFeature-ზე, რომ build-ები იმ მთავარ ვერსიაზე დარჩეს, რომელიც გინდა.