Trouver le code réellement distribué
L’extension EXE ne prouve pas la présence de code .NET managé. Un projet moderne peut produire un apphost natif et une DLL contenant le code IL. Protéger le lanceur ne protège pas la logique de cette DLL. Les bundles single-file et Native AOT sont des formats différents ; commencez ici par une publication classique dans un dossier.
Préparer une entrée contrôlée
La commande d’exemple publie une application dépendante du framework sans apphost. Conservez tout le dossier, y compris .deps.json et .runtimeconfig.json. N’envoyez pas des dépendances au hasard. L’offre gratuite accepte un fichier jusqu’à 1 Mo ; consultez les limites Pro actuelles. Pour un assembly signé, préparez une entrée non signée et gardez les clés privées localement.
Tester le paquet livré
Placez le fichier protégé sous son nom attendu dans une copie du dossier publié. Testez démarrage, arguments, codes de sortie, configuration, ressources et parcours importants. Si une nouvelle signature est nécessaire, effectuez-la localement puis testez à nouveau le paquet signé. Un téléchargement réussi ne démontre pas la compatibilité. L’obfuscation augmente le coût de l’analyse, sans rendre secrète une clé API intégrée au client.
dotnet publish MyApp.csproj -c Release -p:UseAppHost=false -o publish-check
dotnet publish-check/MyApp.dll