.NET-päivitysopas: turvallinen polku ajantasaisiin versioihin

“.NET on nyt vakaa, joten keskitytään ominaisuuksiin”. Tämä kyseinen ajattelumalli toimii siihen saakka, kunnes tietoturvapäivitys, kumppanin SDK tai alustapäivitys vaatiikin yllättäen uudemman ajonaikaisen version. Tässä oppaassa kerromme, milloin olisi hyvä päivittää, miten riskit pidetään kurissa ja miltä hyvä tilanne näyttää vuoden 2025 lopulla.

Miksi tämä on ajankohtaista juuri nyt?

Moderni .NET toimii kahdella eri julkaisulinjalla. LTS oon pitkäaikainen perusversio, jota useimpien palveluiden kannattaisi käyttää. STS puolestaan kehittyy nopeammin ja sopii tiimeille, jotka pystyvät omaksumaan muutokset nopeasti.

Liian suuri viive päivityksissä kasvattaa tietoturva- ja integraatioriskejä sekä vaikeuttaa rekrytointia. Lisäksi se voi myöskin estää tai hankaloittaa tekoälyn käyttöönottoa, koska pilvipohjaiset AI-SDK:t seuraavat tuettuja .NET-linjoja.

Ratkaisuna toimii ennakoitava päivitysrytmi, joka pitää teidät tuettujen versioiden piirissä.

Johdon tarkistuslista ennen päivitystä

1. Tukiaika: mitä .NET-versiota käytätte tällä hetkellä ja milloin sen tuki päättyy?
2. Alustayhteensopivuus: tukevatko keskeiset frameworkit ja pilvi-SDK:t kohdeversiota?
3. Turvaverkot: läpäistäänkö liiketoimintatason testit luotettavassa staging-ympäristössä?
4. Riippuvuudet: ovatko konttikuvat, käyttöjärjestelmäpohjat, CI-ympäristöt ja skannerit ajan tasalla ja yhteensopivia?
5. Julkaisusuunnitelma: voidaanko julkaisu toteuttaa vaiheittain ja onko palvelun tilaa mahdollista seurata ennen laajempaa käyttöönottoa?


Vastaamalla näihin kysymyksiin voitte selvittää ovatko päivitykset hallittuja arpapelin sijaan.

Suunnitelkaa ja toteuttakaa ilman turhaa draamaa

Varmista kohdeversio ja testaa muutosten järjestys pienellä kokeilulla. Julkaise vaiheittain ja seuraa palvelun tilaa. Laajempaan käyttöönottoon kannattaa siirtyä vasta sitten, kun kaikki oleelliset mittarit pysyvät kunnossa. Käytä tietomuutoksissa mallia, jossa vanha ja uusi koodi toimivat rinnakkain koko siirtymän ajan. Ole realistinen palautusten suhteen, sillä jos data on muuttunut, turvallinen eteneminen korjaavan päivityksen kautta on usein se ainoa järkevä vaihtoehto.

Mitä eri .NET-versioista kannattaisi tietää?

Me Netcorpilla keskitymme tuettuihin versioihin. Tuen päätyttyä Microsoft ei nimittäin enää julkaise tietoturvapäivityksiä, ja ekosysteemin yhteensopivuus heikkenee.

.NET 10 (LTS) — julkaistu marraskuussa 2025
Tämä on uusin pitkäaikainen perusversio. Tuoreiden palveluiden kannattaakin tähdätä tähän heti GA-julkaisun jälkeen. Tämä versio saa ensimmäisenä uudet ominaisuudet, suorituskykyparannukset sekä laajan ekosysteemituen.

Miksi tällä on merkitystä: se tarjoaa pisimmän tukijakson ja parhaan yhteensopivuuden tulevien ASP.NET Core-, EF Core- ja pilvi-SDK-päivitysten kanssa.

.NET 9 (STS)
Nykyinen lyhyemmän tuen julkaisu. Tämä sopii tiimeille, jotka liikkuvat nopeasti. Monet toimittajat siirtyvät jo kohti “nyt 9, seuraavaksi 10 LTS” -linjaa.

Viivyttelyn riskit: yhteensopivuus kumppanien SDK-pakettien kanssa heikkenee, kun vanhemmat kohdekehykset poistuvat käytöstä. Tämä voi kaventaa päivitysaikaa ja johtaa ylimääräiseen työhön.

.NET 8 (LTS)
Nykyinen LTS ja erittäin vahva perusvalinta. Useimmat Azure-SDK:t, EF Core 8 ja ASP.NET Core 8 toimivat tässä versiossa. Saat myös Native AOT -parannuksia ja suorituskykyoptimointeja, joita ei ole .NET 6:ssa.

Miksi tällä on merkitystä: pysyt tuetussa, turvallisessa ja yhteensopivassa tilassa samalla kun valmistaudut .NET 10:een.

.NET 6 (LTS) — tuki on jo päättynyt
Tämän version tuki päättyi marraskuussa 2024. Tulet siis kohtaamaan yhä useammin ilmoituksia, joissa vaaditaan .NET 8.0:aa, esimerkiksi EF Coressa, ASP.NET Coressa, analysoijissa ja pilvipalveluiden SDK:issa. .NET 6:n konttien peruskuvat on jäädytetty, mikä siirtää tietoturvariskin käyttöjärjestelmätasolle.

Miksi tällä on merkitystä: kasvavat tietoturvariskit ja lisääntyvä aika, joka kuluu kiertoteihin tuotekehityksen sijaan.

.NET Framework 4.x
Tämä versio on yhä tuettu Windowsin elinkaaren mukaan, mutta uusi kehitys tapahtuu kuitenkin modernissa .NET:ssä. Monet uudemmat Azure - ja kolmannen osapuolen SDK:t edellyttävät .NET 6/8+ -versiota,  joten 4.x-sovelluksissa tarvitaan usein välikerroksia tai vanhempia kirjastoja.

Miksi tällä on merkitystä: integraatiot vaikeutuvat ja rekrytointi hankaloituu.

.NET Framework 3.5 SP1
Tuettu lähinnä vanhojen sovellusten ajamiseen, ei niinkään uuteen kehitykseen. Työkalut ja SDK-ekosysteemi ovat rajallisia.

Miksi tällä on merkitystä: korkeat riskit ja rajalliset vaihtoehdot; migraatio vaatii aikaa.

.NET Framework 3.0 SP2
Tämä versio ei ole ollut enää tuettuna vuoden 2011 jälkeen. Tähän versioon nojautuminen viittaa yleensä laajempaan alustojen ja riippuvuuksien jäykistymiseen.

Miksi tällä on merkitystä: merkittävät tietoturva- ja operatiiviset riskit. Ennen modernien SDK:iden käyttöönottoa tarvitaan vähintäänkin kaksivaiheinen päivitys.

Voiko nykyinen .NET-versiomme käyttää moderneja AI-palveluita?

Kun tiimit sanovat “emme saa AI:ta kytkettyä”, taustalla on yleensä ajonaikaisen version ja SDK:n välinen yhteensopivuusongelma. Alla on käytännönläheinen, versioittainen katsaus Azure OpenAI / OpenAI-, AWS Bedrock & SageMaker- sekä Google Vertex AI -ratkaisuihin.

Mitä SDK:t tukevat (yksinkertaisesti ilmaistuna)

1. Azure OpenAI (.NET) – Azure.AI.OpenAI perustuu .NET Standard 2.0:aan, joten se toimii moderneissa .NET-versioissa (6/8/9/10) sekä .NET Frameworkissa ≥ 4.6.1/4.6.2 tietyin rajoittein. nuget.org
2. OpenAI:n virallinen .NET-kirjasto – yhteensopiva .NET Standard 2.0 -sovellusten kanssa (esimerkit käyttävät .NET 8:aa, mutta kirjasto tukee netstandard2.0:aa). GitHub
3. AWS SDK for .NET (Bedrock/SageMaker) – v4 ei enää tue .NET Framework 3.5:tä, vaan on käännetty .NET Framework 4.7.2:lle ja tukee modernia .NET:iä. Bedrock tarjoaa virallisia .NET esimerkkejä AWS SDK:n kautta AWS-ohjeet+1
4. Google Cloud / Vertex AI (.NET) – kirjastot tukevat .NET Standard 2.0:aa ja .NET Framework 4.6.2+:aa. nuget.org
5. Azure SDK (yleisesti) – rakennettu .NET Standard 2.0:n varaan ja seuraa aktiivisesti modernia .NET-linjaa. Microsoft Learn+2Microsoft for Developers+2

Mitä tämä tarkoittaa käytännössä:

1. .NET 10 (LTS) ja .NET 9 (STS)
   Täysi yhteensopivuus kaikkien keskeisten AI-SDK:iden kanssa. Uusissa palveluissa .NET 10 tarjoaa pisimmän elinkaaren ja parhaan yhteensopivuuden.
   NET-päivitysopas_ Rauhallinen polku …
2. .NET 8 (LTS)
   Vahva perusvalinta tekoälyyn. Azure/OpenAI, AWS ja Vertex AI toimivat hyvin. Lisäksi modernit HTTP- ja gRPC-ominaisuudet ovat oletuksena käytössä. Tämä on turvallisin "julkaise nyt" -kohde kun valmistaudutte .NET10:n käyttöönottoon.
   nuget.org+3nuget.org+3GitHub+3
3. .NET 6 (LTS, tuki päättynyt)
   Tekoäly-SDK:t toimivat edelleen (ne ovat netstandard2.0-yhteensopivia), mutta käytät tukea vailla olevaa ajoympäristöä, mikä lisää tietoturva- ja vaatimustenmukaisuusriskejä sekä rajoittaa tulevia SDK-vaihtoehtoja. Siirry ensisijaisesti versioon 8 tai 10, jotta vältät jäämästä kiinni seuraavan aallon SDK-päivityksiin, jotka saattavat vaatia net6+/net8+.
   NET-päivitysopas_ Rauhallinen polku …
4. .NET Framework 4.7.2–4.8
   Toimii, mutta vain tietyin rajoittein:
   
   1. Azure/OpenAI: OK netstandard2.0:n kautta nuget.org+1
   2. Google Vertex AI: OK (paketit tukevat .NET Framework 4.6.2 tai uudempaa). nuget.org
   3. AWS: Käytä AWS SDK v4:ää (käännetty versioon 4.7.2). Vanhempia kehysversioita (esim. 3.5) ei enää tueta. AWS-ohjeet:
      Nykyaikaisilla gRPC/HTTP2- ja TLS-oletusasetuksilla on odotettavissa enemmän ongelmia kuin .NET 8/10:ssä. Jos päätätte jatkaa tällä alustalla, varatkaa ylimääräistä aikaa riippuvuuksien ja alustan erityispiirteiden selvittämiseen.
5. .NET Framework 4.6.1–4.6.2
   Jotkin tekoälykirjastot toimivat edelleen (netstandard2.0), mutta useat pilvipalveluiden SDK:t vaativat nykyään versiota 4.6.2 tai uudempaa, tai versiota 4.7.2 tai uudempaa, sekä uudempia TLS/HTTP-pinoja. Pitäkää tätä parhaimmillaan väliaikaisena ratkaisuna; siirtyminen nykyaikaiseen .NET-alustaan vähentää integraatioriskejä. GitHub+1
6. .NET Framework 3.5 / 3.0
   Ei sovellu moderneihin tekoälyintegraatioihin. AWS SDK v4 on jättänyt .NET 3.5 -tuen pois, ja nykyiset AI-SDK:t edellyttävät vähintäänkin netstandard2.0-yhteensopivuutta tai uudempaa.
   
   Suunnitelkaa kaksivaiheinen päivitys (Framework → moderni .NET) ennen tekoälyn käyttöönottoa. AWS-ohjeet

Nyrkkisääntö johdolle Jos käytössänne on .NET 8 tai uudempi, olette niin sanotusti “vihreällä alueella” Azure/OpenAI-, AWS Bedrock/SageMaker- ja Vertex AI -integraatioiden osalta. 

.NET Framework -ympäristössä integraatiot ovat usein teknisesti mahdollisia, mutta operatiivisesti kuitenkin melko hauraita. Todelliset kustannukset syntyvät ajasta, joka kuluu kiertoteihin eikä uusien ominaisuuksien rakentamiseen. 

Linjaaminen .NET 8:aan nyt (ja myöhemmin .NET 10:een) pitää teidät näiden AI-SDK:iden ensisijaisessa tukilinjassa.

 

NET-päivitysohje – Rauhallinen polku …

.NET-kohtaiset asiat, joita johdon kannattaa kysyä

1. Kehysyhteensopivuus: Ovatko ASP.NET Core ja Entity Framework -versiot ajan tasalla?
2. Pilvipalveluiden SDK:t: Tukevatko Azure- tai muut pilvipalveluiden SDK:t kohdetta, ja käytämmekö turvallisia versioita?
3. Alustan kunnossapito: Ovatko kontti- ja Windows- tai Linux-peruskuvat tukiaikansa sisällä
4. Toimitusketju: Onko riippuvuudet auditoitu ja skannattu?
5. Henkilöstö ja pääsy: Säilyykö toimintamme jatkuvuus, jos avaininsinöörimme päättää lähteä?

Nämä kysymykset tuovat piilevät riskit esiin ajoissa ja pienentävät päivityskustannuksia.

Millaisia tuloksia johto voi odottaa?

1. Pienemmät riskit: tuettu tietoturvataso ja vähemmän häiriöitä.
2. Nopeammat julkaisut: vähemmän kitkaa CI/CD:ssä ja integraatioissa.
3. Vahvempi rekrytointi: moderni .NET houkuttelee osaajia.
4. Ennakoitavat kulut: jatkuva ylläpito kriisiprojektien sijaan.

UKK päätöksentekijöille

Voiko .NET 6:sta hypätä suoraan .NET 10:een?

Usein tämä onnistuu, kunhan riippuvuudet tukevat sitä. Pyytäkää lyhyt yhteensopivuustarkistus ja pilottivaiheen käyttöönotonsuunnitelma.

Entä .NET Framework -sovellukset?

Ne kannattaa pitää erillään. Siirtäkää vain siellä, missä liiketoimintahyöty on selkeä. Kaikkia sovelluksia ei tarvitse kirjoittaa uudelleen, mutta jokaisella sovelluksella tulisi kuitenkin olla suunnitelma.

Miten käyttökatkot vältetään?



Julkaiskaa vaiheittain ja seuratkaa tuotannon mittareita ennen laajennusta.

Mitä seuraavaksi kannattaisi tehdä?

Pyytäkää yhden sivun nykytilakuvaus: .NET-versiot, frameworkit, pilvi-SDK:t, alustat ja tukiajat. Vahvistakaa päivityspolku pienellä kokeilulla ja suunnitelkaa vaiheittainen käyttöönotto. Tämä kannattaisi toistaa neljännesvuosittain, jotta päivitykset pysyvät hallinnassa.

Olkaa meihin yhteydessä

Suunnittelemme ja toteutamme .NET-päivityksiä rauhallisesti ja mitattavasti. Jos kaipaatte ulkopuolista näkemystä tai toteutusapua projektiin, ottakaa yhteyttä niin voimme aloittaa keskustelun.