Fix Compile Loop in Unity 6.00 by Deferring RedistInstall Execution (Related to issues #654 and #656 .)

[soo-bak]

Overview

This PR addresses the compile loop issue reported in #654 and #656, which occurs when importing Steamworks.NET into Unity 6.00. The issue is caused by immediate operations in RedistInstall.cs—such as writing steam_appid.txt and modifying scripting define symbols (STEAMWORKS_NET)—that are executed during the [InitializeOnLoad] phase.

In Unity 6.00, these operations can unintentionally trigger the compilation pipeline again, leading to repeated recompilation.

Changes

• File modified: RedistInstall.cs
• Key update:
  • Wrapped WriteSteamAppIdTxtFile(), AddDefineSymbols(), and CheckForOldDlls() in EditorApplication.delayCall
  • Added a brief comment to clarify the reason
• Lines changed: ~3
• No other files were modified

Updated static constructor

static RedistInstall() {
    if (EditorUserBuildSettings.selectedBuildTargetGroup != BuildTargetGroup.Standalone)
        return;

    // Delay calls to fix compile issues with custom build profiles in Unity 6.00+
    EditorApplication.delayCall += () => {
        WriteSteamAppIdTxtFile();
        AddDefineSymbols();
        CheckForOldDlls();
    };
}

Why This Fix Works

While trying to understand the root cause behind the issue in Unity 6.00, I spent some time analyzing the compile loop behavior and how it relates to Unity's script reload mechanism and build profile system. Based on my understanding, here's what I believe is happening:

In Unity 6.00, script reloads and define symbol changes are more tightly coupled to the compilation pipeline. When RedistInstall.cs executes immediately during the [InitializeOnLoad] phase, it attempts to:

• Write to disk (steam_appid.txt)
• Modify scripting define symbols in PlayerSettings
• Trigger old DLL detection logic

In earlier versions of Unity, these operations were relatively safe during reload. However, in Unity 6.00, particularly with Custom Build Profiles enabled, Unity interprets these runtime changes as signals to recompile scripts again. Since the static constructor runs every time the domain reloads, this creates a loop: symbol change → recompile → reload → symbol change → ...

By wrapping these calls in EditorApplication.delayCall, the logic is deferred until the next editor frame, after Unity has completed its reload and compilation tasks. This small shift in timing ensures Unity is in a stable state and avoids re-triggering the compilation pipeline.

I tested this fix in multiple Unity 6.00+ projects, including those using several custom build profiles, and confirmed that the compile loop no longer occurs. Editor completes its internal compilation and domain reload cycle, and all intended setup operations complete successfully without triggering further recompilation.

Although this change was primarily motivated by Unity 6.00, I believe this deferred approach can also improve stability in older versions of Unity. Delaying initialization tasks like file I/O or scripting define changes until the editor is fully initialized helps prevent unexpected side effects — especially in projects with custom editor configurations or large codebases.

Compatibility

• Confirmed to work in Unity 6.00.23f1
• Issue reproduced and resolved in a project that used multiple custom build profiles
• Verified compatibility with Unity versions 2017.1 and newer, including 2019.4 LTS, 2020.3 LTS, 2021.3 LTS, and 2022.3 LTS
• Behavior in older Unity versions remains consistent and unaffected

---

Thank you for considering this contribution.
I tried to approach the issue carefully and suggest a minimal change that could safely address the problem. I'm happy to revise further if needed to better align with the direction of the project.

[rlabrecque]

Thanks for this, and the overall care put into this whole submission, especially the testing, makes a ton of sense!

[DylanKontos]

Thanks and fixed!