# Unity Dependencies Hunter: finding the assets your project never references

> Dependencies Hunter scans a Unity project with AssetDatabase, maps every asset to what refers to it, and reports the ones nothing points at, with Addressables and AssetReference handling and a public API you can call from a test. The one thing it cannot see is a reference you build at runtime by string path.

**AlexeyPerov/Unity-Dependencies-Hunter** — This tool finds unreferenced assets by scanning all files in your Unity project.

- Repository: https://github.com/AlexeyPerov/Unity-Dependencies-Hunter
- Stars: 727 · Forks: 80
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/alexeyperov-unity-dependencies-hunter

## One file, and a map built from AssetDatabase

Dependencies Hunter finds and optionally deletes unreferenced assets in a Unity project, and it can also list all the assets in a project and show who references them.

The implementation is unusually portable. All the code is combined into one script, DependenciesHunter.cs, so you can copy and paste it into your project in any Editor folder, or install it through the Unity Package Manager using the repository link. The package manifest names it dependencies-hunter at version 1.4.0, and it declares a minimum Unity version of 2022.3.

The algorithm is three steps, and each one is a specific AssetDatabase call. First it calls AssetDatabase.GetAllAssetPaths() to form a map of all the assets. Then it uses AssetDatabase.GetDependencies to find the dependencies for each of those assets, and as a result a dependencies map is formed. Then it finds all the assets which do not appear as a dependency within that map. Such an asset is considered unused, unless it is marked as to be ignored in the analysis by a list of regular expression patterns.

That construction is the whole reason the tool agrees with Unity. The main analysis is based on Unity's own GetDependencies, so it follows the references Unity exposes through asset serialization and import data. It is not doing its own parsing of the project, which is why it agrees with the editor about what is referenced.

The project is MIT licensed, the default branch is master, the last push was on 2026-10-18, and the repository has no GitHub releases. The top level is small: the Editor directory with the script, the Screenshots~ folder, the package manifest and its meta file, and the licence.

## Addressables are the case that breaks naive asset scanners

Addressables are the reason this tool has options rather than a single switch, and the README explains the problem carefully.

By default, Addressables AssetReference properties are not considered a dependency by AssetDatabase.GetDependencies, and so they are ignored by the tool. That is a false positive waiting to happen, because a scene that loads an asset through an AssetReference field looks to the scanner like it references nothing.

There are three optional settings to address it, and they are separate because they do different jobs.

Scan Addressables AssetReferences treats serialized Addressables AssetReference fields as regular dependencies. Detect Addressables marks assets registered in Addressables settings and keeps them out of delete eligibility, so even if something goes wrong with reference detection, an asset you registered in Addressables is not a candidate. And terrain-data reference scanning can be enabled to catch terrain-related asset links that are easy to miss in regular dependency output.

The AssetReference option has a cost the README is upfront about. Turning it on makes the analysis a little longer, since it changes the underlying mechanics and requires parsing assets as text. So the default is the fast, dependency-based analysis, and the more thorough option is opt-in.

The terrain option exists for a specific reason, and it is the kind of detail that only appears in a tool that has been used on real projects. Terrain data references are linked in a way that does not show up in ordinary dependency output, so a scanner that does not know about it will report a referenced asset as unused.

## The false positives you cannot eliminate

The README has a warning paragraph that is worth reading before you trust any report, and it is more useful than most tools are willing to be.

Runtime-only references are still possible false positives. Assets loaded by string path, custom registries, reflection, remote catalogs, or code-generated paths may not be visible to Unity dependency APIs.

That is a list of five distinct ways to reference an asset without the asset database knowing, and none of them is exotic. A project that builds a prefab path from a configuration value, or that uses reflection to instantiate a type, or that pulls an asset bundle from a server, has references that no static scanner can see. The consequence is that the tool's output is a list of candidates rather than a list of facts, and the difference matters when you are about to delete things.

The Addressables handling reduces one of these categories and the terrain option reduces another, but the general case remains. The tool's own design reflects this, since only assets with zero detected references and not marked as Addressable are eligible for deletion, and the results window has selection and backup controls so you review before applying deletion.

That review step is not decoration. The report is wrong in a specific, predictable way, and the correct response is to look at the assets it names, check whether the project loads them at runtime by path, and only then delete.

## Two windows, and a context menu for the reverse question

The tool has two editor windows, each opened from a menu option, and the primary one is under Tools and Dependencies Hunter.

In that window you can analyze the project and perform unused assets deletion, and only assets with zero detected references and not marked as Addressable, if the Detect Addressables option is enabled, are eligible for deletion. The selection and backup controls in the results window are there so you review the assets before applying the deletion, and the README is explicit that you should use them.

The second window answers the opposite question. You select the assets, use the context menu option "[DH] Find References in Project", and it opens a Selected Assets window with the results. This is the direction you want when you are about to delete something by hand, or when you are trying to work out whether a particular asset is safe to remove.

So the two views answer the two questions that matter. One asks which assets are unused, and the other asks what depends on a given asset, and the second is arguably more useful day to day even though the first is the headline feature.

There is also a settings foldout for the analysis, where you set files to be ignored by providing a list of regular expression patterns, matched against asset paths. You can uncheck the Show Unreferenced Assets Only toggle to view the list of all project assets with their reference counts and file sizes instead.

The ignore patterns are configurable from a file. You can create a custom DependenciesHunterIgnorePatterns.asset under Assets/Editor from the settings foldout, or delete that settings asset to restore the built-in defaults on the next run, and the API picks the patterns up from the same location.

## Running it from CI, with exit codes you can gate a build on

The public API is the part that makes this usable in a pipeline, and it was added specifically for that.

DependenciesHunterApi runs the same analysis without opening a window, so you can fail a build or a test when unused assets appear. Settings are passed explicitly through DependenciesHunterOptions, with defaults that match the window, and the ignore patterns come from the Assets/Editor/DependenciesHunterIgnorePatterns.asset file if it exists.

The EditMode test in the README is short and shows the shape:

```csharp
[Test]
public void ProjectHasNoUnreferencedAssets()
{
    var report = DependenciesHunterApi.FindUnreferencedAssets();

    foreach (var asset in report.UnreferencedAssets)
        Console.WriteLine($"::error file={asset.Path}::Unreferenced asset {asset.Path}");

    Assert.IsFalse(report.HasIssues, report.ToString());
}
```

The Console.WriteLine line is the detail that makes it usable in CI, because it emits a GitHub Actions error annotation in the file= syntax, so the unused assets show up inline on the pull request rather than only in a log.

There is also a command line mode that needs no test framework:

```
Unity -batchmode -projectPath <project> -logFile - \
  -executeMethod DependenciesHunter.DependenciesHunterApi.RunFromCommandLine \
  -reportPath Reports/dependencies-hunter.json
```

The exit code contract is the important part. Zero means no unreferenced assets, one means unreferenced assets were found, and two means the analysis failed. The optional flags are includeReferenced, scanAssetReferences, scanTerrainData and detectAddressables, and the JSON report lists every asset with its type, size, references count and referencing paths.

And there is a second API method, DependenciesHunterApi.FindReferences(paths), which returns the assets referencing each given path, the same result as the context menu command.

## Where Dependencies Hunter is the wrong tool

The first wrong case is a project that loads assets dynamically. If your project builds asset paths at runtime, from configuration, from a remote catalog or from generated code, this tool will report assets as unused that are not. You can compensate with ignore patterns, but the pattern list becomes a parallel inventory of your dynamic references, and it will drift.

The second is a large project where the analysis time matters. Scanning AssetReference fields requires parsing assets as text, and the README notes this makes the analysis longer. On a project with tens of thousands of assets, a full scan on every CI run is a real cost, and the tool gives you no incremental mode described in the documentation.

The third is a team that wants a size report rather than a reference report. The tool shows file sizes alongside reference counts, and that is useful context, but it is not a duplicate detector, it is not an atlas and it will not tell you that two textures are the same image.

The fourth is a project on a newer Unity version than the package declares. The manifest says 2022.3, and while the underlying AssetDatabase calls are long-standing, a tool pinned to a minimum version is a signal about which Unity releases it has been tested against.

The alternative worth weighing is doing nothing and letting the build size grow, which is a legitimate choice for a project where asset size is not a constraint. Where it is a constraint, the reference map is the right tool, and the CI mode with a JSON report is a better long-term answer than deleting by hand, because the gate keeps the problem from coming back.

## Conclusion

Adopt Dependencies Hunter if your Unity project has accumulated assets nobody references and you want the list before you delete anything, since the tool follows the same dependency data Unity itself uses and offers ignore patterns and a backup step before deletion. Keep away if your project loads assets by string path, through reflection, from a remote catalog or from generated paths, because the tool says plainly that those references are invisible to it. Before you delete anything from the report, read the runtime-only references warning, check the exit code contract of the command line mode, and note that the package targets Unity 2022.3 or newer with the version in the manifest at 1.4.0 and the last push on 2026-10-18.

## FAQ

### How does Dependencies Hunter find unreferenced Unity assets?

It calls AssetDatabase.GetAllAssetPaths() to map every asset, then uses AssetDatabase.GetDependencies on each to build a dependency map, then reports the assets that do not appear as a dependency in that map. Because the analysis is built on Unity's own dependency data, it follows the references Unity exposes through asset serialization and import data.

### How do I install Dependencies Hunter in a Unity project?

Either add it through the Unity Package Manager using the repository link, or copy and paste the single DependenciesHunter.cs file into any Editor folder in your project. The whole tool is one script, which is what makes the copy and paste route work.

### Can Dependencies Hunter run in CI and fail a build?

Yes. DependenciesHunterApi runs the same analysis without a window, and the command line mode is Unity in batch mode with -executeMethod DependenciesHunter.DependenciesHunterApi.RunFromCommandLine and a -reportPath for the JSON report. The exit code is 0 for no unreferenced assets, 1 when they are found and 2 when the analysis fails.

### What are the known false positives in Dependencies Hunter?

Assets loaded by string path, through custom registries, via reflection, from remote catalogs or through code-generated paths may not be visible to the Unity dependency APIs, so they can be reported as unused. Addressables AssetReference fields are handled by an opt-in setting, and terrain data references need their own option.

## Sources

- [AlexeyPerov/Unity-Dependencies-Hunter on GitHub](https://github.com/AlexeyPerov/Unity-Dependencies-Hunter)
- [Issues](https://github.com/AlexeyPerov/Unity-Dependencies-Hunter/issues)
- [License: MIT](https://github.com/AlexeyPerov/Unity-Dependencies-Hunter/blob/master/LICENSE)
- [README](https://github.com/AlexeyPerov/Unity-Dependencies-Hunter/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alexeyperov-unity-dependencies-hunter