-
Notifications
You must be signed in to change notification settings - Fork 21
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
MacOS versions incorrectly built/bundled #46
Comments
I need details why it does not works from terminal the MacOS is pretty unstested since a time ago, I did the initial tests on a hackintosh installation and just keep unchanched as possible, but the system updates, dotnet updates and avalonia updates can brick it anytime anyway, so this might be the problem. To the CLI version works you should try give The program using libraries are nothing that bad, that is just if you want keep the executable out of an folder, I let it without any installer to the user be able to save anywhere he wants, if you feel like that is a pain you can build from the source as self contained executable, but I personally does not like that, the same thing with dependencies, while is possible build the standalone app with the .net runtime included it make each updater bigger, and bloat the entire thing for people that already has the dotnet installed, so I like let it like in the old days, everyone installed .net framework and can just run a bunch of apps. Unfortally there are no plans from my side in rewrite the tool, electron is bloated itself anyway since is chromium based, |
For the unzip problem, I recommend trying the github action build as well, since the Github Env is an linux the zip should be done in a way that works for your extractor. |
I got it to extract with correct paths using Archive Utility. I normally use BetterZip Here's what it looks like in Betterzip: The APP version (Intel) doesn't work - just pops an error and won't open via Rosetta. Now trying the ARM64 non-app version. Trying the .desktop file from terminal gives this error (mentioned in another issue):
I'm finally able to open the dll using dotnet as you just instructed. I don't think I would have ever considered to try and open a dll file, nor did I know anything about using "dotnet" to launch something else. Thank you. |
Using Automator I've made a little applet that can be double-clicked in Finder to open the app. It's a wrapper around a simple bash script that just copies the dotnet launch you mentioned above, with full paths to dotnet and the dll. Because none of the files are signed, this required opening the applet 4 or 5 times, each time authorizing a differed dynamic library in security settings. But now it's easy to open. Still need to test, but the PS4 is tied up at the moment. |
I'm glad that it worked, since the only output from the command is If you wrote the bash script to run from the DPI directory (side by side with the executable) share with me and I may let it be included in the next builds for anyone trying use it as well. Unfortally without hackintosh I can't do much support for the MacOS without detailed report as possible. |
I'll try this out later tonight. I'm also going to try something with the Automator file to see if I can streamline it. Currently I've made a folder that can be called anything. Inside this folder is the automator applet. Next to it is a folder called "OSX-ARM64" which was the folder created from your archive. Inside this folder are all your original files. The applet uses AppleScript to get its own parent path and then the bash script calls dotnet with an absolute path and the applet path + OSX-ARM64/...dll It'll work just as easily all inside the same folder. I also want to see if I can put all the files INSIDE the applet, since it's just a regular bundle folder. |
This zip contains the base structure used for the DPI build script, if you are able to adapt it to works with your fixes and we do a test build, I can accept a PR or include it if you just send it here. The current changes that should make the DPI works 100% bundled is change the Settings.ini, Temp directory and Self Update data to somehwere else, what folder you think it fit in macOS to store data like settings and some temp data? |
Zip fixed. |
There is no way to make any MacOS download work as they're not bundled correctly.
Testing on Macbook Air M1
"APP" version:
The file structure has windows path delimiters (back slash) hard-coded into filenames, which prevents them from being recognized as path delimiters on the Mac when unzipped. This just makes a mess of super-long filenames that nothing can be done with.
Non-APP version:
No way to launch executable from finder or terminal. It just plain doesn't work.
I'd suggest the long road of refactoring the whole thing to not use .NET and instead develop as an Electron app to support multiple build targets with all dependencies included. IMO, even the Windows builds are a mess right now with over a dozen files and libraries inside the archive.
The text was updated successfully, but these errors were encountered: