Managed Stripping is disabled under IL2CPP

Under the IL2CPP scripting backend, every managed assembly is converted to C++ and compiled into the player. Code that nothing calls still gets converted and compiled, so Managed Stripping Level: Disabled means shipping the compiled form of code you never run — plus the longer IL2CPP build times that come with more code to process.

What the scan looks at

Player Settings: the scripting backend and the managed stripping level, for the active build target. Reported at Info when the backend is IL2CPP and stripping is disabled.

Why it’s usually off

Because someone hit a reflection bug and turning stripping off made it go away. That’s a real problem with a real fix, and “Disabled” is the wrong one — it trades every byte of dead code for the convenience of not writing a preserve rule.

Stripping breaks reflection-driven code because the linker can’t see a call that’s constructed at runtime: Type.GetType("MyNamespace.MyClass"), JSON deserialization into types nothing statically references, Activator.CreateInstance, and serialization libraries that walk types dynamically.

How to fix it by hand

1. Set Managed Stripping Level to Low and build. Low is conservative and rarely breaks anything.

2. If something breaks, don’t back out — preserve what the linker can’t see. Either the attribute:

   [UnityEngine.Scripting.Preserve]
   public class ThingLoadedByReflection { }

   or a link.xml anywhere in Assets/:

   <linker>
     <assembly fullname="MyGameAssembly">
       <type fullname="MyNamespace.ThingLoadedByReflection" preserve="all" />
     </assembly>
   </linker>

3. Once Low is stable, try Medium. Test the reflection-heavy paths specifically — save/load, mod support, anything type-name driven — because that’s where higher levels bite.

4. Keep the escalation in version control with a note about what needed preserving, so the next person doesn’t “fix” it by disabling stripping again.

The native-side counterpart is Strip Engine Code, which strips unused engine modules for IL2CPP and WebGL builds; PerfLint reports that separately as PROJ011, with a one-click enable.

On a Web build, stripping is the second-biggest size lever, not the first — check the transfer compression before the code size (PROJ010).

What PerfLint does about it

Report-only. Raising the stripping level can break a build in ways only your reflection paths will reveal, so this is a finding that tells you the setting and the trade rather than a button that changes it — unlike the settings whose failure mode is visible immediately, which do get one-click actions.