Packaging and MelonGameVersion

Shipping a mod is a build step, a compatibility declaration, and a distribution decision. The Launcher reads standard MelonLoader metadata and repository manifests to show users what they are installing.

Declare MelonGameVersion

Use MelonLoader’s MelonGameVersion assembly attribute to name the SCP:SL build you compiled and tested against:

using MelonLoader;

[assembly: MelonInfo(typeof(MyMod.Core), "MyMod", "0.3.1", "YourName", null)]
[assembly: MelonGame("Northwood", "SCPSL")]
[assembly: MelonGameVersion("14.2.6")]
[assembly: MelonAdditionalDependencies("Anomaly")]

MelonGameVersion is the primary compatibility metadata for new mods. The older [assembly: AssemblyMetadata("TargetGameVersion", "...")] value is still read as a fallback for older releases, but new examples and packages should use MelonGameVersion.

Missing game-version metadata is allowed, but it makes your mod harder for users to evaluate after SCP:SL updates.

What the Launcher reads

For local DLLs, the Launcher displays:

• Melon / assembly name.
• Mod version.
• Compatible game version, if declared.
• Enabled or disabled state.
• Missing assembly dependencies.

Disabled DLLs are still inspected, so users can see metadata before enabling them again.

Build output

For most client mods, ship one DLL:

<PropertyGroup>
  <OutputType>Library</OutputType>
  <TargetFramework>net6.0</TargetFramework>
  <Nullable>enable</Nullable>
  <LangVersion>latest</LangVersion>
  <GenerateDependencyFile>false</GenerateDependencyFile>
  <CopyLocalLockFileAssemblies>false</CopyLocalLockFileAssemblies>
</PropertyGroup>

Keep Anomaly, MelonLoader, and Unity reference DLLs out of your release package. They are provided by the installed client.

Dependencies

If your mod needs a third-party managed library that is not provided by Anomaly or MelonLoader, declare it clearly.

Repository packages can install shared client libraries into UserLibs/. Manual releases should tell users exactly which extra DLLs are required and where to place them.

Avoid unnecessary dependencies. Shared DLL conflicts are one of the easiest ways to break a modded install.

Asset bundles and UserData

If your mod needs Unity AssetBundle content:

• Build bundles against a compatible Unity version.
• For client-local content, document where the bundle should be placed and how your mod loads it.
• For server-distributed content, put the bundle in the server’s AssetDirectory and load it through AnomalyResources.

Repository packages can ship UserData/ files, but the Launcher treats some paths as user-owned. Package MelonPreferences.cfg, Loader.cfg, and UserData/Skins/ are skipped. Translation files should use UserData/i18n/<namespace>/.

Versioning your mod

Use your own version separately from the game version:

[assembly: MelonInfo(typeof(MyMod.Core), "MyMod", "0.3.1", "YourName", null)]
[assembly: MelonGameVersion("14.2.6")]

• The MelonInfo version is your mod version.
• MelonGameVersion is the SCP:SL build you tested against.

Mention both in your changelog.

Public repository distribution

The Public Repository is the preferred path for player-facing releases. Repository installs can:

• Show mod metadata in the Launcher.
• Filter by compatible game version.
• Install declared dependencies.
• Verify downloaded files before installing.
• Track installed versions for update and uninstall.
• Support anomaly-launcher://install?mod=<id> links.

Public mods are reviewed and scanned for malware before release. Include a clear description, supported game versions, dependency list, license, and changelog when submitting.

Manual distribution

Manual downloads are still useful for private testing or early previews.

At minimum include:

• MyMod.dll.
• A README with the loadout local/Mods/ install path and dependencies.
• A changelog with supported SCP:SL versions.
• Translation files if you localize.

Nice to have:

• A source-code repository.
• Signed releases or checksums.
• Screenshots or short clips for UI-heavy mods.

Manual users need dependency instructions

The Launcher can warn about missing dependencies, but it cannot guess where a private manual release expects every supporting file. Document required DLLs and paths explicitly.

Shipping a client + server mod

If your mod has client, server, and shared components, package them clearly:

MyMod-v0.3.1.zip
|-- client/
|   |-- MyMod.Client.dll
|   `-- MyMod.Shared.dll
|-- server/
|   |-- MyMod.Server.dll
|   `-- MyMod.Shared.dll
`-- README.md

Use the same compiled shared assembly on both sides. Do not rebuild separate client and server copies from diverging source.

Next

Compatibility, IL2CPP Patterns, and Troubleshooting.