Find Mono Assembly Requirements Safely with mono-find-requires

You will finish with a reproducible way to feed Mono assemblies and configuration files to mono-find-requires, inspect the dependency lines it emits, and explain an empty result. The command is a packaging helper, not a general-purpose application dependency browser.

Allow about fifteen minutes. You need Ubuntu's mono-utils package, a shell, and paths to the files you are packaging. The examples were checked with mono-utils version 6.8.0.105+dfsg-3.6ubuntu2. Run the inspection as an ordinary user unless the input files cannot be read; nothing in the normal workflow changes installed software or package metadata.

1. Confirm the installed helper

Check the path and package version before relying on its output:

$ command -v mono-find-requires
/usr/bin/mono-find-requires
$ dpkg-query -W -f='${Package} ${Version}\n' mono-utils
mono-utils 6.8.0.105+dfsg-3.6ubuntu2

The local manpage is deliberately sparse. It says to use the help switch, but this installed Bash script accepts that word as ordinary input context and prints nothing. Its actual interface is visible in the script: it reads a newline-separated file list from standard input and prints RPM-style requirements to standard output.

2. Build a newline-separated file list

Pass one path per line. The helper selects names ending in .exe or .dll for assembly inspection and names ending in .config for native library mappings:

$ find /path/to/package-root -type f \( -name '*.dll' -o -name '*.exe' -o -name '*.config' \) -print
/path/to/package-root/usr/lib/myapp/MyApp.exe
/path/to/package-root/usr/lib/myapp/MyApp.dll.config

That find command only prints names. It does not modify the package tree. Avoid feeding arbitrary untrusted text into the list: the script stores the lines in a shell array, so unusual names containing shell whitespace or expansion characters are not a good test case for this legacy helper. For a controlled package build, use the package builder's file list or a temporary list containing known paths.

To inspect a small, known set without creating a file:

$ printf '%s\n' \
    /path/to/package-root/usr/lib/myapp/MyApp.exe \
    /path/to/package-root/usr/lib/myapp/MyApp.dll.config \
  | mono-find-requires

3. Read assembly requirements

The script calls monodis --assemblyref for each selected assembly. It converts the referenced assembly name and version into lines such as:

mono(System.Core) = 4.0.0.0
mono(System.Xml) = 4.0.0.0
mono(mscorlib) = 4.0.0.0

These are package-build dependency hints in the RPM naming style, not commands to run and not proof that Debian's package manager will resolve them. The script sorts and removes duplicates, then keeps requirements that are not also provided by the inspected assemblies. If an assembly references a library supplied by another input file, that reference can disappear from the final output.

$ find /path/to/package-root -type f \( -name '*.dll' -o -name '*.exe' -o -name '*.config' \) -print \
  | mono-find-requires \
  | tee /tmp/myapp-mono-requires.txt
$ test -s /tmp/myapp-mono-requires.txt && echo 'requirements found'
requirements found

4. Include native libraries from .config files

Configuration scanning looks for Mono <dllmap> entries and prints the value of their target attribute. Entries restricted to another operating system are skipped. The script then asks rpm -q --whatprovides which package provides each native library.

That second lookup is RPM-specific. Ubuntu systems may not have rpm, so a config-only dependency can produce a warning and no package name. This is a limitation of the helper, not evidence that the native library is unused. If you only need assembly references, explicitly disable config scanning:

$ printf '%s\n' /path/to/MyApp.dll \
  | IGNORE_CONFIG_SCAN=1 mono-find-requires

IGNORE_CONFIG_SCAN=1 leaves assembly analysis enabled. It is useful when an RPM lookup is unavailable or when you are deliberately handling native dependencies in packaging metadata yourself. Record that decision in the package recipe.

5. Diagnose empty output

Empty output is often expected. The script ignores files that do not end in .dll, .exe or .config, and an assembly may have no unresolved references. Test the input selection first:

$ printf '%s\n' /path/to/MyApp.dll | mono-find-requires
$ printf 'status: %s\n' "$?"
status: 0

A zero status means the script completed, not that it found a dependency. If a recognised assembly still produces nothing, run monodis --assemblyref /path/to/MyApp.dll and confirm that the file is a readable managed assembly. The helper suppresses monodis diagnostics, so this separate check is the quickest way to distinguish an empty dependency set from a bad input.

The script also exits quietly when DISABLE_MONO_RPM_AUTO_DEPS is set. Check the environment if a known-good list suddenly gives no output:

$ env | grep '^DISABLE_MONO_RPM_AUTO_DEPS=' || true
$ env -u DISABLE_MONO_RPM_AUTO_DEPS sh -c \
  'printf "%s\n" /path/to/MyApp.dll | mono-find-requires'

6. Treat build-root overrides as packaging controls

The helper normally looks for monodis under /usr/bin and Mono libraries under /usr/lib. Packaging systems that analyse a staged root can set prefix to that root's prefix. This changes where the helper looks for its analysis tools; it does not rewrite your input paths or install anything.

Do not add sudo merely because the package is being built. Use elevated privileges only when your build environment specifically requires access to a protected staging tree. If the helper reports monodis missing or unusable, verify the selected prefix and the executable and library paths before changing permissions or copying files.