Class SerenityPackageImportScrubber
Post-import cleanup for Serenity package updates: the package is the sole owner of
Assets/Serenity/Scripts, Tests and Documentation, so once an import has laid its
files down, any file still under those roots that the import did not deliver is a leftover from a
previous version and goes to the OS trash (recoverable). Media/ is never touched (users modify
prefabs and themes in place).
The cleanup deliberately runs AFTER the import, never before. An earlier design trashed the owned roots
on importPackageStarted so the import could lay everything down fresh; that is self-defeating and
was removed. Unity does not release a trashed asset's GUID within the same import transaction, so every
incoming file carrying a just-trashed GUID was skipped: the working install was destroyed while only
assets with no prior GUID (genuinely new modules) were written back, leaving a fraction of the package
on disk and no framework that compiles. Importing additively — letting same-GUID files overwrite in
place and cleaning up afterwards — delivers the package intact.
Accepted destructive edge: partial Custom Package imports of the framework folders are UNSUPPORTED — a file the user deselects during a Serenity import is not part of the imported items, so the safety net treats the on-disk copy as a leftover and moves it to the trash (recoverable). This is a product decision, not an accident: those folders belong to the package, and deselecting framework files would otherwise leave exactly the stale-orphan states this mechanism exists to eliminate.
Inherited Members
Namespace: Serenity.Editor.ObsoleteAssetCleaner
Assembly: Serenity.ObsoleteAssetCleaner.Editor.dll
Syntax
public static class SerenityPackageImportScrubber