1. Identify what you are distributing
The .exe extension does not prove that a file contains managed .NET code. Modern SDK projects commonly produce a native apphost plus a DLL containing your IL. The apphost launches that DLL. Obfuscating the launcher does not protect the application logic. A single-file bundle, Native AOT output and an ordinary managed assembly are different inputs; start with an ordinary folder publish for this workflow.
2. Make a controlled input build
For a framework-dependent example, publish with UseAppHost=false as shown below. This leaves a managed DLL you can launch with dotnet. Keep the entire output directory, including .deps.json and .runtimeconfig.json. Do not upload runtime dependencies at random. The free website accepts one file up to 1 MB; check Pricing for current Pro batch and size limits. Strong-name signed or delay-signed input requires an unsigned build for this service. Keep private signing keys local.
3. Test the actual release package
Upload the managed assembly, download the protected file and place it under the expected assembly filename in a separate copy of the publish directory. Preserve the original build. Test startup, arguments, exit codes, configuration, resources and the main business workflows. Re-sign locally when your distribution requires it, then test the final signed package again. A successful download is not a compatibility test. Obfuscation raises reverse-engineering effort; it does not make a client-side API key secret.
dotnet publish MyApp.csproj -c Release -p:UseAppHost=false -o publish-check
dotnet publish-check/MyApp.dll