Archisteamfarm: Crash on start of linux specific v4.1.0.3

[Gilrain]

Hi,
Trying to launch the lastest linux specific stable (v4.1.0.3), ASF-linux-x64.zip, I get the following error:

An assembly specified in the application dependencies manifest (ArchiSteamFarm.deps.json) was not found:
  package: 'runtimepack.Microsoft.NETCore.App.Runtime.linux-x64', version: '3.0.0'
  path: 'System.IO.Compression.Native.a'

The file is present in the archive and installed with the rest of program.

Deleting all the entries in ArchiSteamFarm.deps.json pertaining to the shipped _*.Native.a_ files is enough to restore the program to a functionning state.

OS: Arch Linux x64
.Net: v3.0.0 (tested with the barebone _host_ and the complete _runtime_ packages)

[JustArchi]

I can't reproduce this on my clean Debian x64 box. Nobody else has reported this issue either so far, so I'm heading towards arch/setup issue for now.

Can you show your output of ldd System.IO.Compression.Native.so? Are you sure that System.IO.Compression.Native.a file is actually available in ASF directory? It is included in the linux-x64 package.

[Gilrain]

Sorry, my mistake.
I didn't properly check that the staticlibs where indeed installed (ouch). The packaging method as been rectified to account for those newly introduced libraries.

[JustArchi]

If it helps then inclusion of .a files in self-contained builds actually looks like a mistake by .net core sdk and is supposed to be corrected in the future, but nonetheless it's a good idea to ensure that all files included as part of the build release are also available in the target directory, even if it looks like something isn't actually needed (because it might be needed during specific ASF action in specific ASF environment, and crash might not outright happen, which is why dependencies file ensures the base minimum of "all those required files are verified to be at least available").

In any case I'm happy that you found out about the mistake, let me know if anything else comes up as I'm always happy to help package maintainers with their issues in regards to bundling ASF, it's also a part of ASF development, even if a bit of third-party.