-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert to .NET Framework #494
Conversation
The launcher has not introduced any .NET 4.8 incompatible codes for now. Is introducing Polyfill necessary? See: CnCNet/dta-mg-client-launcher#13 |
Update progress. Now, the client can be successfully built in .NET 4.8. Several commitments of mine require additional check:
|
In my opinion, .NET 7 target can be preserved, as |
Now the client runs successfully |
Definitely Polyfill. Switching to PolySharp brings additional compile errors, while Polyfill works. Although Polyfill has missing Index/Range issue but it should be an MSBuild-related issue. Therefore, making a workaround 9a1ab74 for it is acceptable. |
1b987c4 Changing assembly loading priority is needed so that people could just override the binaries folder without deleting it first. Explain in example: This commit changes the priority so even if "Binaries\ClientCore.dll" is not deleted, the client should be able to launch as it finds the correct "Binaries\Windows\ClientCore.dll". Possible con: If a dll was a specific one and become a common one now, user must delete the old dll file. |
All assemblies except UniversalGL work fine at a quick glance. Below are logs of an attempt to launch UniversalGL on Windows and Linux |
Should be fixed in f6acb03 |
|
Thanks for the help. However, the latest commit a2bbf5a brings some changes which, in my opinion, requires further discussions:
|
a2bbf5a
to
47f779b
Compare
TODO:
|
WindowsGL builds (both for .NET 4.8 and .NET 8) fails because of this commit: Rampastring/Rampastring.XNAUI@f32bcda |
Upstream dependencies prerequisites:
After these pull requests are merged and new packages are released, those "*.(s)nupkg" files acting as temporary files can be removed from this branch |
1a2ffed
to
781b07f
Compare
All works are done. We could either wait for upstream dependencies updates or just merge this PR before the dependencies updates (temporarily preserving those NuGet packages files in Ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see anything I had an issue with. May be worth waiting for approval from someone with stronger C# experience if you want style feedback though.
ef6d648
to
25834a4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Outstanding work, although as the OG author of the PR I can't approve that. I have no complaints apart from the one I left.
DXMainClient/Program.cs
Outdated
// SearchResourcesDir is copied from ClientCore | ||
private static string SearchResourcesDir(string startupPath) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think should add the explanation for this and a cref to the original method to a docstring so that if someone updates one of the methods the second would need to be updated too, and a comment in the second place backreferencing that one.
aea8b9d
to
aa4e9bd
Compare
ccfafbf
to
7808d16
Compare
Co-Authored-By: Rans4ckeR <[email protected]> Co-Authored-By: Kerbiter <[email protected]>
7808d16
to
bede1ac
Compare
Description
.NET 7 provides considerably worse user experience for average desktop user over .NET Framework and brings many issues for distribution .NET Framework 4.8 is still going to be supported for a good while and supports most modern tech from C# 11 because of .NET Standard 2.0 support and many backports, and because the changes are not tremendous to go back to .NET Framework it was decided to do so.
The proposed way
Currently I suggest to take the current develop and with power of polyfills, backports and git reverts where there's runtime/API incompatibility (like default interface implementations) make the current version work on .NET Framework 4.8. The reason is there is a lot of changes since the revert and reapplying them one by one would be, in my opinion, a great headache with conflicts and such, and current code is pretty stable from our limited testing with @Starkku in Project Phantom closed beta.
TODO