MacOS versions incorrectly built/bundled about directpackageinstaller

[marcussacana]

I need details why it does not works from terminal
The bundled version is really deprecated, but it should at least works for send direct links.
The tool works on linux so it shouldn't have a problem like that on macos.

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 chmod +x and be sure that the command dotnet works, in last case execute DPI directly with help of the dotnet with dotnet DirectPackageInstaller.Desktop.dll this should bypass executable permissions problems.

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,
But I can try fix any error that is sent detailed enought to me find where is the problem.

[marcussacana]

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.
But this type of thing is more a fault of the compressor (PowerShell/Microsoft.PowerShell.Archive#54) than mine, if the compressor changed the path deliminator it should solve the problem for both system, if the decompressor detect the incompatible deliminator it should works as well.
The nexts builds I will give a try in use the GH action builds instead the ones made in my PC, I just do that because my PC is faster than the GH Actions

[HVR88]

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):

zsh: killed ./DirectPackageInstaller.Desktop

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.

[HVR88]

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.

[marcussacana]

I'm glad that it worked, since the only output from the command is zsh: killed ./DirectPackageInstaller.Desktop and the dotnet way still works, means that something is wrong with the executable made by .net runtime, and can be anything since are no details at all about the error.
May I ask you to test the build from this artifact?
https://github.com/marcussacana/DirectPackageInstaller/actions/runs/8760926760/artifacts/1431249281
Since this build is made in linux maybe the things may work...

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.

[HVR88]

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.

[marcussacana]

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.
https://github.com/marcussacana/DirectPackageInstaller/blob/main/Files/OSXAppBase.zip

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?

[marcussacana]

Zip fixed.