Open xoascf opened 2 years ago
I can add an NSIS installer for this.
Also offer something else like multi-architecture support with AnyCPU configuration (so that the same .exe can run on x86, x64 and ARM). That way you will no longer have to compile more than one version per architecture.
My understanding is that .NET Core does not support AnyCPU builds that run on multiple architectures.
My understanding is that .NET Core does not support AnyCPU builds that run on multiple architectures.
Oh, in that case, it is possible to downgrade to .NET Framework 4 to make it work, and have another target for .NET Core, I once made some changes to run RetroBar (Windows Vista with .NET Framework 4.6.1) and it worked as AnyCPU on x86 and x64.
It seems to work fine on Windows Vista (32 bit) as AnyCPU with .NET Framework 4.6.1, but sometimes it doesn't show the Windows Media Player icon in the taskbar, for the volume icon you have to open and close sndvol.exe
to get it to appear in the tray, and the Properties window has no icon.
I can add an NSIS installer for this.
As long as we rely on "CPU architecture-agnostic" dependencies, it should not be necessary to make an architecture dependent version, it could also use a version of the .NET Framework that already comes pre-installed in the most recent versions of Windows (4.6.1 works fine with some changes), so we don't have to install anything else. The installer should not depend on the architecture either, as it could also be provided as AnyCPU, and its content (the program) would be a resource that is extracted when installing.
You could try this test build I made yesterday, there should be no noticeable changes.
My understanding is that .NET Core does not support AnyCPU builds that run on multiple architectures.
Oh, in that case, it is possible to downgrade to .NET Framework 4 to make it work, and have another target for .NET Core, I once made some changes to run RetroBar (Windows Vista with .NET Framework 4.6.1) and it worked as AnyCPU on x86 and x64.
This could be possible in the next major runtime update, which will be .NET Framework 4.8.1, as it will offer ARM64 support natively.
Please not, the OSS .NET 6 (Core) is platform independent and has more is more sustainable as the .NET Framework.
Please not, the OSS .NET 6 (Core) is platform independent and has more is more sustainable as the .NET Framework.
That has nothing to do here, if it were for that, we would use Mono completely, but as there is no WPF support for Mono, nor .NET Core on non-Windows platforms, nothing can be done about it, except a rewrite of the program with its own cross-platform graphical subsystem or using Avalonia with the changes it would require.
When the application is installed it should open the program as previously intended, but instead of installing to AppData/Local install to a custom location as in issue #29.
It should also automatically update the program configuration (this works if the original .exe is replaced, not many do this and may complain that the configuration was not updated) or provide a better way to handle the configurations as in .json files (as in updater) instead of using user.config.
A better way to provide the program may be to simply have the files compressed in the .zip, instead of a single .exe file, so theme creators and translators can change themes and translations directly without going to AppData/Local or the way it was previously preferred.
Also offer something else like multi-architecture support with AnyCPU configuration (so that the same .exe can run on x86, x64 and ARM). That way you will no longer have to compile more than one version per architecture.