Portálási terv létrehozása

Mielőtt belevág a kódba, szánjon időt a javasolt áttelepítés előtti lépések végrehajtására. Ez a cikk bemutatja, hogy milyen típusú problémák merülhetnek fel, és segít a legértelmesebb megközelítés kiválasztásában.

Fontos

Az API-port elavult a bináris elemzés javára a .NET Upgrade Assistant eszközzel. Az API-port háttérszolgáltatása le lett állítva, ezért az eszköz használatához offline állapotban kell használnia. További információ: .NET API Port README.

Portolja a kódot

Mielőtt továbbmenne, győződjön meg arról, hogy követi a kódportolás előfeltételeit. Készüljön fel arra, hogy eldöntse, melyik a legjobb módszer az Ön számára, és kezdje el a kód áthelyezését.

Fontos

A .NET Upgrade Assistant hivatalosan elavult. Ehelyett használja a GitHub Copilot modernizációs csevegőügynököt , amely a Visual Studio 2026 és a Visual Studio 2022 17.14.16-os vagy újabb verziójában érhető el. Ez az ügynök elemzi a projekteket és a függőségeket, részletes migrálási tervet készít célzott javaslatokkal és automatizált kódjavításokkal, és véglegesíti az egyes módosításokat, hogy ön érvényesíthesse vagy visszaállíthassa azokat. Automatizálja a gyakori portolási feladatokat – a projektfájlok frissítését, az elavult API-k cseréjét és a buildelési problémák megoldását –, így kevesebb manuális munkával gyorsabban modernizálható.

Elsősorban a fordítóval foglalkozik

Ez a megközelítés jól működik olyan kis projekteknél vagy projekteknél, amelyek nem használnak sok .NET-keretrendszer API-t. A megközelítés egyszerű:

  1. Ha szeretné, futtassa az ApiPortot a projekten. Ha az ApiPortot futtatja, a jelentésből megismerheti a kezelni kívánt problémákat.
  2. Másolja át az összes kódot egy új .NET-projektbe.
  3. Miközben a hordozhatósági jelentésre hivatkozik (ha létrejön), a fordítási hibákat a projekt teljes fordításáig oldja meg.

Bár strukturálatlan, ez a kódközpontú megközelítés gyakran gyorsan megoldja a problémákat. Ehhez a megközelítéshez ideális lehet egy olyan projekt, amely csak adatmodelleket tartalmaz.

A .NET-keretrendszer használata a hordozhatósági problémák megoldásáig

Ez a módszer akkor lehet a legjobb, ha a teljes folyamat során lefordított kódot szeretné használni. A megközelítés a következő:

  1. Futtassa az ApiPortot egy projekten.
  2. A problémákat különböző, hordozható API-k használatával oldhatja meg.
  3. Jegyezze fel azokat a területeket, ahol nem használhat közvetlen alternatívát.
  4. Ismételje meg az összes portolt projekt korábbi lépéseit, amíg biztos abban, hogy mindegyik átmásolható egy új .NET-projektbe.
  5. Másolja a kódot egy új .NET-projektbe.
  6. Dolgozzon ki minden olyan problémát, amelynél azt észlelte, hogy nem létezik közvetlen alternatíva.

Ez a gondos megközelítés strukturáltabb, mint a fordítóhibák egyszerű megoldása, de még mindig viszonylag kódközpontú, és annak az előnye, hogy mindig vannak lefordított kódjai. Az, hogy hogyan oldhat meg bizonyos problémákat, amelyeket nem sikerült megoldani egy másik API használatával, nagyban eltér. Előfordulhat, hogy egy átfogóbb tervet kell kidolgoznia bizonyos projektekhez, amelyet a következő megközelítés foglalkozik.

Átfogó támadási terv kidolgozása

Ez a megközelítés nagyobb és összetettebb projektek esetében lehet a legjobb, ahol a kód szerkezetátalakítására vagy bizonyos kódterületek teljes újraírására lehet szükség a .NET támogatásához. A megközelítés a következő:

  1. Futtassa az ApiPortot egy projekten.

  2. Ismerje meg, hogy hol használják a nem hordozható típusokat, és hogy ez hogyan befolyásolja az általános hordozhatóságot.

    • Ismerje meg ezeknek a típusoknak a természetét. Kis számban vannak, de gyakran használják őket? Számban nagyok, de ritkán használják őket? A használatuk koncentrált, vagy az egész kódban elterül?
    • Könnyű elkülöníteni a nem hordozható kódot, hogy hatékonyabban tudja kezelni?
    • Kell-e refaktorálni a kódját?
    • Azoknál a típusoknál, amelyek nem hordozhatók, vannak alternatív API-k, amelyek ugyanazt a feladatot hajtják végre? Ha például az osztályt WebClient használja, használja inkább az osztályt HttpClient .
    • Vannak különböző hordozható API-k a feladat elvégzéséhez, még akkor is, ha nem teljesen helyettesítik az eredetit? Ha például xml-elemzést használ XmlSchema , de nem igényel XML-sémafelderítést, api-kat használhat System.Xml.Linq , és az API-k használata helyett saját maga is implementálhatja az elemzést.

  3. Ha vannak olyan szerelvények, amelyeket nehéz portolni, érdemes lehet egyelőre a .NET Frameworkon hagyni azokat? Íme néhány megfontolandó szempont:

    • Előfordulhat, hogy a kódtár bizonyos funkciói nem kompatibilisek a .NET-tel, mert túl nagy mértékben támaszkodik .NET-keretrendszer vagy Windows-specifikus funkciókra. Érdemes egyelőre hátrahagyni ezt a funkciót, és kiadni a tár ideiglenes .NET-verzióját kevesebb funkcióval, amíg az erőforrások nem lesznek elérhetők a szolgáltatások portjára?
    • Segítene egy kód átszervezés?

  4. Ésszerű megírni egy nem elérhető .NET-keretrendszer API saját implementációját?

    Megfontolhatja a .NET-keretrendszer referenciaforrásból származó kód másolását, módosítását és használatát. A referencia forráskód licenccel rendelkezik az MIT-licenc alapján, így jelentős szabadsága van arra, hogy a forrást saját kódjának alapjául használja. Csak győződjön meg arról, hogy megfelelően tulajdonítja a kódban a Microsoftnak.

  5. Ismételje meg ezt a folyamatot szükség szerint a különböző projektek esetében.

Az elemzési fázis a kódbázis méretétől függően eltarthat egy ideig. A szükséges módosítások hatókörének alapos megismeréséhez és egy terv kidolgozásához szükséges idő általában időt takarít meg a végén, különösen ha összetett kódbázissal rendelkezik.

A terv magában foglalhat jelentős módosításokat a kódbázison, miközben továbbra is a .NET-keretrendszer 4.7.2-t célozza meg. Ez az előző megközelítés strukturáltabb verziója. A terv végrehajtásának menete a kódbázistól függ.

Vegyes megközelítés

Valószínű, hogy a fenti megközelítéseket projektenként fogja keverni. Tegye meg, ami önnek és a kódbázisának a legértelmesebb.

A tesztek átvitele

A legjobb módja annak, hogy a kód portolás után minden működjön, ha a kódot folyamatosan teszteli, amint a .NET-re portolja. Ehhez egy tesztelési keretrendszert kell használnia, amely teszteket készít és futtat a .NET-hez. Jelenleg három lehetőség közül választhat:

Végső soron a portálási munka nagymértékben függ a .NET-keretrendszer kód strukturáltságától. A kód portolásának jó módja, ha a kódtár alapjaival kezdesz, amelyek a kód alapvető összetevőit alkotják. Ezek lehetnek adatmodellek vagy más alapszintű osztályok és metódusok, amelyeket minden más közvetlenül vagy közvetve használ.

  1. Portozza a tesztprojektet, amely teszteli az éppen portolásra használt kódtár rétegét.
  2. Másolja át a könyvtára alapját egy új .NET-projektbe, és válassza ki a támogatni kívánt .NET Standard verziót.
  3. Végezze el a kód fordításához szükséges módosításokat. Ennek nagy része a NuGet-csomag függőségeinek hozzáadását igényelheti a csproj-fájlhoz .
  4. Futtassa a teszteket, és végezze el a szükséges módosításokat.
  5. Válassza ki a következő kódréteget a portoláshoz, és ismételje meg az előző lépéseket.

Ha a kódtár alapjával kezdi, és kifelé halad az alaptól, és szükség szerint teszteli az egyes rétegeket, a portolás egy szisztematikus folyamat, amelyben a problémákat egyszerre egy kódrétegre külön-külön kell elkülöníteni.

Következő lépések

  • Last updated on