Names can be application contracts
Normal compiled calls can follow renamed metadata references, but external text does not automatically follow them. Reflection such as Type.GetType, type names in configuration, plugin discovery, JSON property names and WPF binding paths may depend on the original spelling. List these boundaries before enabling aggressive protection. Start with the smallest change and test against a known baseline; a generic promise that an assembly loads is not enough.
Build a consumer, not just a loader
For a DLL, run a real consumer compiled against the original public API. Call interfaces, inherited members, generics and async methods. Exercise JSON serialization and deserialization in both directions using saved expected documents. Load plugins by the same route used in production, read embedded resources and open UI screens that use bindings. If several owned assemblies must be processed together, validate references across the set and keep external dependencies unchanged.
Treat signing and mapping as release artifacts
Retain an unsigned input when using a service that rejects signed assemblies, and re-sign only inside your trusted build pipeline. Do not upload private keys. If a rename map is produced, keep it with the matching protected build and restrict access: it reveals original names. Decode a representative exception trace using that exact map. An empty map may mean that no eligible names changed; it is not proof of corrupt output. Finally rerun the deployed package, including its configuration and dependent files, before replacing a customer-facing installation.