Map und Build gemeinsam aufbewahren
Dokumentiere SHA256 von Eingabe und Ausgabe, Optionen, Assembly-Identität und Map-Datei zusammen. Eine Map verrät Originalnamen und gehört in zugriffsbeschränkten Release-Speicher. Eine Map aus einem anderen Build kann plausible, aber falsche Namen liefern. Gleiche Dateiendung oder Produktversion reicht nicht als Zuordnungsnachweis.
Eine bekannte Ausnahme nachvollziehen
Löse in einer Staging-Kopie einen kontrollierten Fehler ohne Kundengeheimnisse aus. Dekodiere den Trace mit der exakten Map und prüfe erwartete interne Typ- und Methodennamen. Bewahre das Original auf und vergleiche unveränderte Frames. Veröffentliche keine privaten Traces oder Maps als Demonstration.
Leere und teilweise Ergebnisse einordnen
Eine exportierte Map ohne Einträge kann gültig sein, wenn keine geeigneten Namen geändert wurden. Der Decoder soll den Trace dann unverändert lassen. Ein fehlerhaftes Format ist etwas anderes. Unveränderte Frames können öffentliche Mitglieder, Abhängigkeiten oder generierten Code betreffen. Prüfe zuerst, ob Map und Build zusammengehören.
Namen sind keine Zeilennummern
Eine Rename-Map stellt nicht automatisch Quellpfade oder Zeilen her. Symbolikation benötigt passende Assemblies und Debug-Symbole; Optimierungen können sichtbare Frames verändern. Bewahre Diagnoseartefakte nach deiner Aufbewahrungsrichtlinie auf und teste das Verfahren vor dem Release. Verteile Maps nicht an alle Kunden, wenn du ihre Inhalte nicht offenlegen möchtest.
Get-FileHash ./MyLibrary.obfuscated.dll -Algorithm SHA256
Get-FileHash ./MyLibrary.map.txt -Algorithm SHA256
# Record these with the release ID and protection options.