Class ModDependencyService

Namespace

McServerLauncher.Services

Assembly

McServerLauncher.dll

The library mods almost every mod needs, and that nobody remembers to install by hand.

public class ModDependencyService

Inheritance

object

ModDependencyService

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

The symptom is the Fabric loader refusing to start with a list like "Explorify needs any version of fabric-api, which you do not have" and "Towns and Towers needs cristallib 3.1.3 or later". Nothing was broken: the app installed exactly the jar that was asked for and none of the ones it depends on.

Modrinth publishes those dependencies per version, so they can be resolved rather than guessed. Two things are worth knowing about that data. Dependencies carry no version range — a dependency either pins one exact version id or names a project and takes whatever is current — which is why "the project is already installed" is a complete answer here and not an approximation. And embedded means the dependency is bundled inside the jar already, so installing it again is how you get two copies of the same mod and a different startup failure.

Only required is installed. Optional dependencies are suggestions, and pulling them in would quietly fill the folder with mods nobody chose.

Modrinth is not the only source, because it is not always right. Checked on 2026-08-30: Explorify v1.6.5 declares no dependencies at all on Modrinth, while its own fabric.mod.json says "fabric-api": "*" — and fabric-api is exactly what the loader refused to start without. So the jar is read as well, and it is the authority on what it needs.

Constructors

ModDependencyService(ModrinthService?)

public ModDependencyService(ModrinthService? modrinth = null)

Parameters

modrinth ModrinthService

Methods

ResolveByModIdAsync(IEnumerable<string>, ServerType, string, IEnumerable<string>, CancellationToken)

The same, for mod ids read out of a jar rather than project ids given by Modrinth.

public Task<ModDependencyService.Plan> ResolveByModIdAsync(IEnumerable<string> modIds, ServerType loader, string mcVersion, IEnumerable<string> installedProjectIds, CancellationToken ct = default)

Parameters

modIds IEnumerable<string>

loader ServerType

mcVersion string

installedProjectIds IEnumerable<string>

ct CancellationToken

Returns

Task<ModDependencyService.Plan>

Remarks

A mod id is not a Modrinth project id. Most library mods use the same word for both (fabric-api is the clear case), and the ones that do not — cristallib is published as cristel-lib — simply do not resolve. That is why nothing here is reported as unresolved: an id Modrinth has never heard of is not evidence that anything is missing, and saying so would turn a guess into a warning.

ResolveMissingAsync(IEnumerable<VersionResult>, ServerType, string, IEnumerable<string>, CancellationToken)

The required dependencies of roots, transitively, minus what is already installed.

public Task<ModDependencyService.Plan> ResolveMissingAsync(IEnumerable<VersionResult> roots, ServerType loader, string mcVersion, IEnumerable<string> installedProjectIds, CancellationToken ct = default)

Parameters

roots IEnumerable<VersionResult>

loader ServerType

mcVersion string

installedProjectIds IEnumerable<string>

ct CancellationToken

Returns

Task<ModDependencyService.Plan>