Skip to content

LoggerPro — Runtime/Migration

The one-time move of configuration out of the package, for projects upgrading from 1.x.

This code runs once, against a real user's real settings, and there is no second chance. That is why it is the part of the runtime assembly the test suite reaches into: the failure mode is a team's category list being replaced by defaults, silently, on upgrade.

LoggerProConfigMigration.cs — copies a legacy LoggerProConfig and LoggerProSettings asset into the new JSON store.

Two rules it follows:

  • Only carry a path forward if the user actually chose it. The pre-2.0 defaults pointed inside the package folder, so copying those over would faithfully preserve the very defect the migration exists to escape. IsDeliberateChoice is what decides, matching the old defaults by tail so a relocated package is still recognised.
  • Never delete the legacy assets. Removing files a user might have referenced, customised or checked in is their decision. It reports what it found instead.

When more than one candidate asset exists it says so and names the ones it ignored. It used to take whichever AssetDatabase.FindAssets returned first and report that path alone, so a project with a stray second copy silently adopted an arbitrary one as its pre-2.0 truth.

LoggerProPresetMigration.cs — moves category view presets out of the package folder.

Guarded on a presetsMigrated flag so a user who deliberately deleted every preset does not get them back on each load — but the flag alone is not enough. It travels in the committed JSON while the presets it records are per machine, so a teammate who pulled the flag without the folder never ran the recovery and was told "No presets found." while their legacy presets sat in Assets untouched. The migration re-runs when the destination folder is empty.

Testing this

Runtime/Core/AssemblyInfo.cs grants InternalsVisibleTo("LoggerPro.Tests") largely for this folder. What the tests pin is the dangerous direction: that migration does not fire when there is nothing to migrate, which is the state every user is in on every domain reload after the first. Exercising the write path would mean planting legacy assets in a real project, and that is not covered — Tests/README.md says so rather than implying otherwise.