Associer la correspondance au build
Conservez ensemble SHA256 d’entrée et de sortie, options, identité d’assembly et fichier de correspondance. Celui-ci révèle les noms d’origine et nécessite un accès restreint. Un fichier d’une autre compilation peut produire des noms plausibles mais faux. Une extension ou une version de produit identique ne suffit pas à prouver l’association.
Reproduire une exception connue
Déclenchez un échec contrôlé dans une copie de test, sans secrets clients. Utilisez la correspondance exacte dans le décodeur et vérifiez les types et méthodes internes attendus. Conservez la trace initiale et comparez aussi les frames inchangées. Ne publiez pas de correspondances ou traces privées pour illustrer l’outil.
Comprendre les résultats vides ou partiels
Une correspondance exportée sans entrée peut être valide si aucun nom admissible n’a changé. Le décodeur doit conserver la trace plutôt qu’inventer des noms. Un format incorrect est un autre problème. Les frames inchangées peuvent venir d’une API publique, d’une dépendance ou de code généré. Vérifiez d’abord le lien avec le build.
Le nom n’est pas la ligne source
Une correspondance de renommage ne retrouve pas automatiquement les fichiers source ni les lignes. La symbolication nécessite assemblies et symboles compatibles ; l’optimisation peut modifier les frames visibles. Conservez les artefacts de diagnostic selon votre politique et testez le processus avant publication. Ne distribuez pas ces fichiers à tous les clients si vous ne souhaitez pas révéler leur contenu.
Get-FileHash ./MyLibrary.obfuscated.dll -Algorithm SHA256
Get-FileHash ./MyLibrary.map.txt -Algorithm SHA256
# Record these with the release ID and protection options.