LoggerPro — LoggerProTools (Lite Integration)¶

This folder holds the tooling an asset author uses to ship LoggerProLite inside their own Unity asset.

It contains one file:

• LiteBrandingTool.cs

This README previously documented a LoggerProLiteSyncTool.cs, a "Tools ▸ LoggerPro ▸ Lite Integration ▸ Sync Categories to Lite" menu item, a LoggerProLiteCategoryConfig asset and a LoggerProLitePrefsUtility. None of those have ever existed in this package. The workflow they described — keeping a shared Lite config in step with your own categories — was the pre-2.0 model, where every vendor shipped the same LoggerProLite assembly. That model is what the branding tool exists to replace.

LiteBrandingTool.cs¶

Generates a private, branded copy of LoggerProLite for one asset.¶

Tools ▸ LoggerPro ▸ Lite Integration ▸ Prepare Lite For My Asset

Lite is redistributed inside other people's products, so the hard problem is not logging — it is what happens when a user installs two assets that both ship it. A shared assembly means a duplicate assembly name, duplicate types, and a Resources config that shadows whichever copy imported second. The project does not compile.

The tool removes that failure mode by giving each vendor a copy that cannot collide with anyone else's.

What it generates¶

From a vendor name and an asset name it derives an identifier — Acme — and writes:

<destination>/AcmeLite/
  LoggerProLite-LICENSE.md      ← attribution; keep it, see LICENSE.md condition 4
  Editor/
    Acme.Lite.asmdef            ← Editor-only assembly, unique name
    DevLog.cs                   ← and the rest of the templates, un-.txt'd
    ...
  Resources/
    AcmeLiteConfig.asset        ← your identity + categories

and rewrites, in every copied template:

The last two matter more than they look. EditorPrefs are per-user per-machine and shared across every Unity project on it, so two vendors leaving those keys identical means one console's filters silently become the other's — in every project on that machine. And the Create-asset entry produces a type internal to one vendor's assembly, so an identical entry from another vendor creates a config that nothing can load back.

Categories¶

The generated config's category list starts empty and fills itself: Lite registers a category the first time your tool logs to it, exactly as LoggerPro does. There is nothing to sync.

The two-stage run¶

Generate() cannot create the config asset on a first run, because the assembly it belongs to has not compiled yet. The tool writes the sources, asks Unity to recompile, and finishes the job from a [DidReloadScripts] continuation whose state lives in SessionState.

If that continuation does not run — an interrupted reload, a compile error elsewhere in the project — the console says so and the config can be created by hand from the <Asset Name> ▸ Console Config entry the generated code registers.

Before you ship¶

• Keep LoggerProLite-LICENSE.md in the folder. It is how you satisfy condition 4 of LICENSE.md, and it tells whoever finds the folder later where support comes from.
• Do not hand-copy LoggerProLite/ instead of running this. Its files are .cs.txt templates: left as .cs they compile into LoggerPro's own assembly, where Lite's internal types produce CS0122 in every script of yours that calls DevLog.
• Read LoggerProLite/README.md for what your users get and what a report contains.