Sign and Check .NET Assemblies with Mono sn

A build pipeline that suddenly refuses to load your assembly with a strong-name error is what sends most people to sn for the first time. This guide gets you to a small, repeatable workflow for creating a strong-name key pair, reading its public identity, and checking or comparing CLR assemblies. The examples use Mono StrongName 6.8.0.105 from Ubuntu package mono-devel version 6.8.0.105+dfsg-3.6ubuntu2.

Allow about fifteen minutes. You need a shell and an assembly or key file to inspect. The examples that create files run as an ordinary user. Do not use sudo for key generation or signing: making a private key readable by root or another account creates an avoidable access problem.

1. Confirm the installed command

Check the executable and package version before relying on examples. These are read-only checks:

$ command -v sn
/usr/bin/sn
$ dpkg-query -W -f='${Package} ${Version}\n' mono-devel
mono-devel 6.8.0.105+dfsg-3.6ubuntu2
$ sn -h sn
Mono StrongName - version 6.8.0.105

The manual describes sn as a tool for digitally signing, verifying and comparing strong names on CLR assemblies. The installed binary reports its version in help output; sn --version is not a supported option here and prints an unknown-option error.

Checkpoint: If command -v sn finds nothing, stop and install the distribution package through your normal system-management process. Do not download a replacement binary into the project directory.

2. Generate a private key pair

Choose a new path that does not contain an existing key. The -k option creates an SNK file and uses a 1024-bit key when no size is supplied:

$ install -d -m 700 "$HOME/strongname-keys"
$ sn -k "$HOME/strongname-keys/example.snk"
A new 1024 bits strong name keypair has been generated in file '/home/YOU/strongname-keys/example.snk'.
$ ls -l "$HOME/strongname-keys/example.snk"
-rw------- 1 YOU YOU 596 ... example.snk

Replace YOU in the displayed path with your account name when reading the output. The private half is inside this file, so keep it out of source control and backups that are not meant to hold signing keys.

Warning: This step changes your home directory by creating one key file. If it was the wrong path, remove only that newly created file after checking it carefully, for example with rm -- "$HOME/strongname-keys/example.snk". That deletion is irreversible and destroys the private key.

3. Inspect the public identity

Use -tp to print the public key and its token without exposing the private key:

$ sn -tp "$HOME/strongname-keys/example.snk"
Mono StrongName - version 6.8.0.105
Public Key:
0024000004800000940000000602000000240000525341310004000001000100...

Public Key Token: 48d3439ccda1204c

Your public key and token will differ. The token is a short identity commonly used when referring to a strong-named assembly. Use -t when you need only the token from a key file. Use -T or -Tp for an assembly rather than an SNK file:

$ sn -t /path/to/Library.dll
$ sn -Tp /path/to/Library.dll

These commands read the supplied file. They do not sign it and do not alter machine configuration.

4. Verify an assembly signature

For an assembly produced by your build, run -v:

$ sn -v /path/to/Library.dll
Mono StrongName - version 6.8.0.105
Assembly /path/to/Library.dll is strongnamed.

The exact diagnostic depends on the file. A successful command should report that the assembly is strong-named and return status zero. Treat a non-zero status or an unrecognised signature as a release problem, not as a reason to bypass verification. Run the check against the exact artefact you plan to ship, not just an intermediate build output.

-vf performs the verification even when verification has been disabled by configuration. That makes it useful for an explicit diagnostic, but it does not repair a bad signature:

$ sn -vf /path/to/Library.dll
$ printf 'verification status: %s\n' "$?"
verification status: 0

The status line is produced by the shell. It is the exit status from sn, not proof that every consumer will accept the assembly. Keep the command output with the build record when signature provenance matters.

5. Compare two builds without their signatures

Use -D when two assemblies should contain the same metadata but have different signatures:

$ sn -D build/Library.dll release/Library.dll
Assembly 1 and Assembly 2 are the same except for the signature.

The manual describes this as a metadata-hash comparison. A successful comparison does not mean the files are byte-for-byte identical. If the command reports a difference, compare the build inputs, target framework and compiler output before replacing either artefact.

6. Keep configuration changes separate

The manual lists machine-level strong-name configuration under machine.config, including verification settings and public-token mappings. Options such as -c and -m are not supported by this Mono build. The -Vr, -Vu and -Vx verification-exemption options are also documented as unsupported and require manual configuration editing.

Security boundary: Do not edit machine.config merely because a verification command failed. Such edits affect other applications and normally need elevated privileges. First confirm the assembly path, public token, build key and command version. If a development exemption is genuinely required, back up the relevant configuration, make the smallest documented change during a maintenance window, and record an undo plan that restores the original file. Never use a verification exemption to hide a production signing failure.

The key-container options -d, -i and -pc also change or expose machine-managed key material. They are outside this basic file-based workflow. Do not run them against a shared container until you know which account and build process depend on it.

Done means