Revert to .NET Framework

[Metadorius]

See CnCNet/xna-cncnet-client#494 for details.

I already figured out most of the changes, what's left is technical work and evaluation.

Currently what's needed to be done here:

• Finish the changing of FileStream constructors to old API
• Decide if the backport of sockets handler is OK to use
• Sort out the polyfills to use, see parent PR

[SadPencil]

I just realized that in order to keep the compatibility of both .NET 4.8 and .NET 7.0, it is better to switch this project to .NET Standard 2.0

Update: since we still need to determine whether the client is .NET 8 or 4.8, this project is retained as a .NET 4.8/8 project. Hmm, we need to merge this project into xna-cncnet-client considering the high coupling

[Metadorius]

I am not sure if the project can be compiled under .NET Standard though, I thought it's a pseudo target and a DLL/EXE can't be compiled this way?

[SadPencil]

I am not sure if the project can be compiled under .NET Standard though, I thought it's a pseudo target and a DLL/EXE can't be compiled this way?

should be fine. dotnet pack command generates the package files needed by the client. After specifying this project as .NET Standard 2.0, when compiling the client in .NET 7, the related warning messages would not show again.

[SadPencil]

Check whether the second stage updater could run successfully as a single file exe. PR #6 brings a DLL dependency (obsolete; not needed)

[SadPencil]

Now, this PR brings the support of the old clientupdt.dat updater as well as the new second stage updater. Both cases are tested on my machine.

[Metadorius]

No complaints either, although not sure where did the .NET Standard as target idea go.

[SadPencil]

not sure where did the .NET Standard as target idea go.

currently there are #if !NETFRAMEWORK to differ the client’s behavior in ClientUpdater library (e.g., whether .NET 4.8 or .NET 8.0 second-stage updater should be launched), so ClientUpdater.dll is not a .NET Standard library right now