MSBuild will fail when the nuget packages are cached in a path that contains whitespaces. This can be fixed by adding " to the exec statement.

Replace this line

with

<Exec Command="&quot;$(MSBuildThisFileDirectory)../tools/$(_OSIdentifier)-$(_OSHostArch)/upx&quot; $(_UpxArgs) $(NativeBinary)" />

When will.NET8 be supported?

I noticed that there are only linux-x64 and win-x64 in the tools directory, which makes me think that linux musl-x64 is not supported.

But after my actual test, I'm glad that it can work normally in the linux-musl-x64 (mcr.microsoft.com/dotnet/sdk:7.0.100-alpine3.16-amd64) environment. :) 👍 💯

Can you update the README.md file to let more people know this?

Finally, thank you for your great contribution !!! 🥇 🥇 🥇

Hi,

I see there is only support for x86_64 for both Windows and Linux. Would it be possible to add linux-arm64?

When I tried to manually download binary for arm64 from https://github.com/upx/upx/releases/tag/v3.96 and placed it into
.nuget/packages/publishaotcompressed/0.0.3/tools, publish of "Hello world" app was successful, but after running, I got
segfault

After publishing a NativeAOT app with UPX and PublishLzmaCompressed, it randomly crashes at startup with an error code 127. I've seen it happening about 1 times out of 1000 on Alpine, and less frequently on other distributions.

UPX is definitely the culprit. I don't know if it's an UPX issue affecting all applications (hadolint/hadolint#475 looks related, there's also upx/upx#385 but it's supposedly fixed) or a weird interaction with NativeAOT. I'm mostly opening this issue for awareness.

I haven't been able to reproduce the issue with a simple Hello World. I assume that the issue is dependent on the size of the app.