Implement Migration Tool

[MahBoiDeveloper]

Closes #750

To Do List

• Write patches for each release with major config changes
• Add embedded missing images and copy them if they are absent in Resource folder
• Fix Migration-INI.md wrong Edit GlobalThemeSettings.ini section
• Add documentation with migration tool description and detailed steps for migration workflow
• Test MT with old client configs samples
  • Mental Omega 3.3.6
  • Twisted Insurrection
  • Tiberian Sun Client
  • YR client package
  • YR Mod Base
  • Rise Of The East

[github-actions]

Nightly build for this pull request:

• artifacts.zip
  This comment is automatic and is meant to allow guests to get latest automatic builds without registering. It is updated on every successful build.

[SadPencil]

That's why I suggest using a list of strings

Set this list manually is a mistake. But I have found another way to organize this list. We can just use enum extension to get all values of Version enum.

seems good

[SadPencil]

Including clientcore? What if polyfill requires a lot of dll files (like the updater in 2.12.0)

[MahBoiDeveloper]

Including clientcore? What if polyfill requires a lot of dll files (like the updater in 2.12.0)

It is a good question how to include already existed enums into migration tool.

[SadPencil]

Including clientcore? What if polyfill requires a lot of dll files (like the updater in 2.12.0)

It is a good question how to include already existed enums into migration tool.

Just repeat the definition for now? I don't have a better way

[MahBoiDeveloper]

This doesn't feel right

[SadPencil]

This doesn't feel right

yeah. Let's just repeat the definition.

[MahBoiDeveloper]

yeah. Let's just repeat the definition.

@Metadorius what do you think? I agree with @SadPencil to reduce numbers of libs by repeating the definitions.

[Metadorius]

Why can't you reuse the same libs the client uses?

BTW, this is one of the reasons I proposed for it to be a part of the client invoked as a command line parameter.

[MahBoiDeveloper]

BTW, this is one of the reasons I proposed for it to be a part of the client invoked as a command line parameter.

Client assembly differences with libraries between different versions (like Rampastring.Tools.dll near to clientdx.exe that crash client on start) should not affect the migration tool. That's why I decided to make it as cli-tool in executable file.

[Metadorius]

Client assembly differences with libraries between different versions (like Rampastring.Tools.dll near to clientdx.exe that crash client on start) should not affect the migration tool. That's why I decided to make it as cli-tool in executable file.

Do we really need to inconvenience ourselves that much because of issues of wrong binaries? IMO we would save a lot of hassle by not handling the problems with binaries. The migration tool doesn't apply 100% of the needed changes anyway, so it's not like we will lose a lot by not handling this.

[MahBoiDeveloper]

@SadPencil Would you like to help with WindowsXNA Release NET4.8 target build? I don't know how to fix compilation for this target.

[SadPencil]

@SadPencil Would you like to help with WindowsXNA Release NET4.8 target build? I don't know how to fix compilation for this target.

I guess you'll have to consult @frg2089 for this error. Maybe you can also try moving the tool inside the DXMainClient project to avoid touching the build files

[MahBoiDeveloper]

I guess you'll have to consult @frg2089 for this error. Maybe you can also try moving the tool inside the DXMainClient project to avoid touching the build files

Never mind, I managed to solve the problem myself. The issue was the build target.