Die eigentliche Assembly finden
Eine EXE muss keinen verwalteten .NET-Code enthalten. Moderne Projekte erzeugen häufig einen nativen apphost und eine DLL mit dem IL-Code. Eine Änderung am Starter schützt nicht die Programmlogik der DLL. Single-File-Bundles und Native AOT sind andere Ausgabeformate; beginne hier mit einer normalen Ordnerveröffentlichung.
Einen kontrollierten Build erstellen
Der Beispielbefehl veröffentlicht eine frameworkabhängige Anwendung ohne apphost. Bewahre den vollständigen Ordner einschließlich .deps.json und .runtimeconfig.json auf. Lade nicht wahllos Abhängigkeiten hoch. Kostenlos ist eine Datei bis 1 MB möglich; aktuelle Pro-Grenzen stehen unter Pricing. Für signierte Assemblies benötigst du einen unsignierten Eingabe-Build. Private Schlüssel bleiben lokal.
Das tatsächliche Paket prüfen
Setze die heruntergeladene Assembly unter ihrem erwarteten Namen in einer Kopie des Publish-Ordners ein. Teste Start, Argumente, Exitcodes, Konfiguration, Ressourcen und wichtige Abläufe. Signiere bei Bedarf anschließend lokal und teste das signierte Paket erneut. Ein erfolgreicher Download ist kein Kompatibilitätsnachweis. Obfuskation erhöht den Analyseaufwand, schützt aber keinen im Client eingebetteten API-Schlüssel als echtes Geheimnis.
dotnet publish MyApp.csproj -c Release -p:UseAppHost=false -o publish-check
dotnet publish-check/MyApp.dll