Generate Faster Mono XML Serializers with sgen

You will finish with a generated Assembly.XmlSerializers.dll beside a Mono assembly, ready for an application that uses XmlSerializer. This guide uses sgen from Mono 6.8.0.105 on the local system, whose tool reports runtime version 4.0.30319.42000. Allow about fifteen minutes if your assembly is already built. You need a readable .NET assembly, a shell, and the mono-devel package. The commands generate files in a chosen directory; they do not install or register anything system-wide.

1. Confirm the installed tool

Check that the command is available and record the package version:

$ command -v sgen
/usr/bin/sgen
$ dpkg-query -W -f='${Package} ${Version}\n' mono-devel
mono-devel 6.8.0.105+dfsg-3.6ubuntu2
$ sgen --help
Mono Xml Serializer Generator Tool
Mono version 4.0.30319.42000

The installed help output is brief, so use the manpage for the option meanings. The relevant inputs are an assembly and, when needed, its referenced assemblies. The tool generates a separate serializer assembly rather than modifying the input DLL.

2. Build or locate the input assembly

sgen needs a compiled assembly, not a C# source file. For a quick self-contained test, create a small library in a working directory:

$ mkdir -p ~/sgen-demo
$ cd ~/sgen-demo
$ mcs -target:library -out:Widget.dll Widget.cs

Use your own existing DLL if you already have one. A minimal Widget class with a public Name property is enough to demonstrate the command, but the useful production case is an assembly containing the serializable types your application actually uses. Check the path before continuing:

$ test -r Widget.dll && file Widget.dll
Widget.dll: PE32 executable (DLL) ...

If the check fails, stop and fix the path or read permission. Do not run the generator as root just to make an incorrectly located file work.

3. Generate the serializer in a separate directory

Create a destination and pass the assembly with the long option form. The colon belongs between the option and its value in this form:

$ mkdir generated
$ sgen --nologo --assembly:Widget.dll --out:generated
Generated assembly: Widget.XmlSerializers.dll
$ find generated -maxdepth 1 -type f -printf '%f\n'
Widget.XmlSerializers.dll

The default output directory is the current directory, but an explicit --out keeps generated artefacts away from source and build files. The output name is derived from the input assembly. If you use an assembly called Orders.dll, expect Orders.XmlSerializers.dll.

$ test -s generated/Widget.XmlSerializers.dll && echo 'serializer generated'
serializer generated

A successful message only tells you that generation completed. Keep this DLL with the matching input assembly and test it through the application that will load it.

4. Select a type only when you need to

By default, sgen processes the assembly. Use --type when you need to name a runtime type explicitly:

$ mkdir selected
$ sgen --nologo --assembly:Widget.dll --type:Widget --out:selected
Generated assembly: Widget.XmlSerializers.dll

The value is the runtime type name, not a source filename. For a namespaced class, use its fully qualified name, such as Example.Models.Order. If the type cannot be resolved or the assembly cannot be loaded, correct the assembly and dependency paths first. Do not infer that an output DLL is valid merely because a destination file was created.

5. Handle references and compiler options carefully

If the target assembly refers to another assembly that the generator cannot resolve, supply that dependency with --reference:

$ sgen --nologo \
    --assembly:Orders.dll \
    --reference:Contracts.dll \
    --out:generated

Repeat the option for each required referenced assembly if the installed tool accepts the set your build needs. Keep the dependency files from the same build as the target. Mixing versions can produce a serializer that compiles but does not match the application at runtime.

The --compiler option passes compiler options through to the generation step. Treat it as a build-system setting, not a place for shell syntax. Quote values according to the command's argument rules and review the resulting build output. --debug asks the compiler to generate debug information. --keep keeps temporary generated source files for inspection, which is useful when diagnosing a failed build but can leave extra files in the output area.

6. Avoid accidental replacement

Running the same generation command again does not silently replace the serializer. It exits with an error similar to this:

$ sgen --nologo --assembly:Widget.dll --out:generated
Cannot generate assembly '.../generated/Widget.XmlSerializers.dll' because it already exist. Use /force option to overwrite the existing assembly

This protection matters because overwriting a known-good serializer can disrupt a build or leave you unsure which generated file was tested. Generate to a new directory first, compare or test the result, then update the build output in the normal way.

Use --force only when replacement is deliberate:

$ sgen --nologo --force \
    --assembly:Widget.dll \
    --out:generated

7. Keep scripts quiet without hiding failures

--silent suppresses normal progress output, while --verbose requests more progress detail. Neither option changes the generated serializer. In a script, preserve and check the exit status:

if sgen --silent --assembly:Widget.dll --out:generated; then
    test -s generated/Widget.XmlSerializers.dll
else
    status=$?
    printf 'sgen failed with status %s\n' "$status" &2
    exit "$status"
fi

Do not treat silence as success, and do not ignore a non-zero exit status. Add a separate file check because a later build step may remove or replace the generated file.

8. Know the boundary of this tool

--proxytypes is listed by the installed manpage but marked as not supported yet. Do not build a workflow around it. The tool generates serializer classes for the older Mono 2.0 profile family described by the manual; this installed command's exact runtime and compiler compatibility still depend on the target assembly and the rest of your build. Test the generated DLL with the application and framework profile that will load it.

No command in this guide needs elevated privileges. Avoid sudo: it can make generated files root-owned and hide an ordinary path or permission mistake. If your build directory is not writable, choose a writable working directory or fix ownership through your normal administration process.