← வலைப்பதிவு

ஜூலை 21, 2026 · 6 நிமிட வாசிப்பு

majorsilence-migrate மூலம் ஒரு WinForms பயன்பாட்டை இடம்பெயர்த்தல்

இந்தப் பக்கம் ஒரு மொழிபெயர்ப்பு. ஆங்கிலப் பதிப்புடன் வேறுபாடு இருந்தால், ஆங்கிலப் பதிப்பே சரியானது. English

majorsilence-migrate என்பது ஒரு WinForms solution ஐ Majorsilence.Forms க்கு நகர்த்துவதைத் தானியக்கமாக்கும் CLI கருவி. அதன் மைய வடிவமைப்பு முடிவு எளிதில் கவனிக்கப்படாமல் போகக்கூடியது; எனவே அதை வெளிப்படையாகக் குறிப்பிடுவது பயனுள்ளது: அது syntax tree ஐ parse செய்வதும் இல்லை, symbols ஐத் தீர்ப்பதும் இல்லை. அது மூல உரையின் (raw source text) மீது பல சுற்றுகளில் இயங்கும் ஒரு உரை/regex மீள்எழுதி (rewriter) — அது வேண்டுமென்றே அவ்வாறு உருவாக்கப்பட்டது.

ஏன் உரை அடிப்படை, Roslyn அல்ல

கருவியின் சொந்த மூலக் குறியீட்டுக் குறிப்பிலிருந்து (source comment): “இது வேண்டுமென்றே உரை அடிப்படையிலான மாற்றம் — இது syntax tree ஐ parse செய்வதில்லை — இதனால் இது வேகமாகவும், தற்போது compile ஆகாத கோப்புகளைப் பொறுத்துக்கொள்வதாகவும் இருக்கிறது.”

அந்தச் சமரசம், symbol-அறிவு கொண்ட ஒரு கருவி வழங்க முடியாத இரண்டு விஷயங்களைத் தருகிறது:

விலை: projects களுக்கு இடையிலான உண்மையான symbol resolution இல்லை. ஒரு வெறும் Panel குறிப்பு System.Windows.Forms.Panel ஐக் குறிக்கிறதா அல்லது அதே பெயருடைய உங்கள் சொந்த class ஐக் குறிக்கிறதா என்பதை மீள்எழுதியால் எப்போதும் கூற முடியாது — அதற்குப் பதிலாக அது namespace-prefix மற்றும் using/Imports சூழலைச் சார்ந்திருக்கிறது. நடைமுறையில் இது அரிதாகவே தெளிவற்றதாக இருக்கும் (WinForms மற்றும் Telerik type பெயர்கள் தனித்துவமானவை); அது அடையாளம் காணாத எதுவும் அமைதியாக ஊகிக்கப்படுவதற்குப் பதிலாக, கைமுறை மதிப்பாய்வுக்காகக் குறிக்கப்படுகிறது.

விருப்பத்தேர்வான Roslyn இயந்திரம்

உண்மையிலேயே தெளிவற்ற சந்தர்ப்பத்துக்கு — அதே கோப்பில் ஒரு WinForms/GDI+ type உடன் அதே வெறும் பெயரைப் பகிரும் ஒரு custom type — விருப்பத்தின் பேரில் இயக்கக்கூடிய இரண்டாவது இயந்திரம் உள்ளது: --engine roslyn. இது regexes க்குப் பதிலாக MSBuildWorkspace ஐயும் உண்மையான symbol resolution ஐயும் பயன்படுத்துகிறது; உரை இயந்திரத்தை மாற்றீடு செய்யாமல் அதன் மேல் அடுக்கப்படுகிறது. Roslyn பயன்முறையிலும் பல சுற்றுகள் உரை அடிப்படையிலேயே இருக்கின்றன, ஏனெனில் அவை ஆரம்பத்திலிருந்தே symbol-resolution பிரச்சினைகள் அல்ல.

சமரசங்கள் இயல்புநிலை இயந்திரத்துக்கு நேர் எதிராக உள்ளன: MSBuild மூலம் உண்மையில் ஏற்றப்படும் ஒரு solution அல்லது project இதற்குத் தேவை (ஒரு வெறும் directory அல்லது தனிக் கோப்பு எச்சரிக்கையுடன் உரை இயந்திரத்துக்குத் திரும்பும்); MSBuild மதிப்பீடே இயக்க நேரத்தை ஆக்கிரமிப்பதால் இது பல மடங்கு (orders of magnitude) மெதுவானது; ஒரு project ஏற்றத் தவறினால், அந்த project இன் கோப்புகள் மட்டுமே உரை இயந்திரத்துக்குத் திரும்பும் — இயக்கம் நிறுத்தப்படாது. MSBuild ஐயே கண்டுபிடிக்க முடியாவிட்டால், அமைதியாகத் தரம் குறைவதற்குப் பதிலாக முழு இயக்கமும் கடுமையாகத் தோல்வியடையும்.

எப்போது இதைப் பயன்படுத்துவது: இயல்புநிலை --engine text உடனான முதல் சுற்றுக்குப் பிறகு, ஏற்கனவே சுத்தமாக ஏற்றப்படும் ஒரு project இல், diff இல் குறிப்பிட்ட, உறுதிப்படுத்தப்பட்ட பெயர் மோதல் (name-collision) சந்தர்ப்பத்தைக் காணும்போது. பெரிய, ஒருவேளை பாதி உடைந்த legacy codebase மீதான ஆரம்பச் சுற்றுக்கு, இயல்புநிலை உரை இயந்திரமே இன்னும் சரியான கருவி.

அடுத்தது என்ன

ஒவ்வொரு சுற்றின் முழு விவரத்துக்கும் repository இல் உள்ள MIGRATION.md ஐயும், உங்கள் இடம்பெயர்க்கப்பட்ட குறியீடு compile ஆனதும் உண்மையில் எவை செயல்படுத்தப்பட்டுள்ளன என்பதற்கு COMPATIBILITY_MATRIX.md ஐயும் பாருங்கள்.