For packages that consist of 100% managed code, "Architecture: all" must be chosen in debian/control.

Packages containing a mix of managed and native code must be "Architecure: any" or depending on the specific package a more restricted set of architectures is valid.

The package's applications, libraries and meta-data must be installed into /usr/lib/upstream_package_name .

Libraries that will be installed into the GAC must be installed into /usr/lib/cli/assembly_name-X.Y (for more details about the X.Y version see GAC versioning). assembly_name is the assembly name without the file extension (.dll). The commonly seen /usr/lib/mono/upstream_package_name path should only be used for Mono project packages.

Example path for the log4net package: /usr/lib/cli/log4net-1.2

Never install native "glue" libraries into /usr/lib, instead install them at /usr/lib/cli/assembly_name-X.Y . When moving libraries update the references to the new location using a DLL Map. See the Mono DLL maps section for an example.

The only exception here is for native libraries that are of wider use; can be used other packages. Native libraries should be packaged according to the in a Debain Policy conformant way.

You must not install application files (.exe) directly into /usr/bin. Instead create a wrapper script into /usr/bin to allow them to be run without path and the .exe suffix.

Source code files (*.cs, *.vb, *.boo, etc.) should be non-executable.

Library files (*.dll) should be non-executable.

Debug symbol files (*.mdb) should be non-executable.

Assembly config files (*.config) should be non-executable.

Application files (*.exe) must have the executable flag (+x) set to enable compatiblity with direct invokation as ./foo.exe using Linux's BINFMT support.

To ensure that all files have correct permissions, you should use Debhelper's /usr/bin/dh combined with cli.make. Otherwise you should add dh_clifixperms after dh_fixperms in the binary-* targets of debian/rules.

At a minimum, CLI packages should Build-Depends on cli-common-dev (>= 0.7) and the appropriate CLI compiler or CLI SDK package.

Current CLI compilers in Debian: C#: mono-mcs (>= 1.0) | c-sharp-compiler C# 2.0: mono-gmcs (>= 1.1.8) | c-sharp-2.0-compiler C# 3.0: mono-gmcs (>= 1.2.5) | c-sharp-3.0-compiler Nemerle: nemerle (>= 0.9) Boo: boo (>= 0.5.6) Current CLI SDKs in Debian: Mono: mono-devel (>= 2.4.2.3)

Software that uses Mono via the C interface library (libmono.so) or requires the /usr/lib/pkgconfig/mono.pc file must Build-Depends on libmono-dev (>= 1.0)

Note that there are architectures for which no CLR is available and thus you may have to restrict the Build-Depends for your package to the architectures available.

If your package is Architecture: all, you should specify this as Build-Depends-Indep. Never put debhelper, cdbs, dpatch and quilt into Build-Depends-Indep. See the for more information on this.

Libraries that are installed into the GAC must be strong-named, i.e. signed.

Libraries must to be installed into the GAC at package install time (postinst) which is provided by the dh_installcligac tool of the cli-common-dev package.

Each of the libraries in the GAC has an assembly version number that consists of 4 parts (major, minor, build and revision number). When loading libraries from the GAC all 4 parts and the public signing key fingerprint must match.

It is general practice and that a library is ABI compatible when only the build and revision number change and the major and minor number stay the same.

The library package name must be prefixed with lib.

To reflect the ABI stability and prevent breakages when a ABI-incompatible version is released, a similar solution for is used. The major and minor number must mirror the SONAME version and the resulting package name should be libfooX.Y-cil, where X is the major and Y the minor number of the assembly version.

One notable exception for this naming are assemblies that end on a number (Mono.C5 for example). In this case the package should be named libfoo123-X.Y-cil (i.e. libmono-c5-0.5-cil) to improve the readability.

The -cil suffix is chosen to prevent confusion with native library package names. Never use "sharp" in the package name as it does not represent the language, and a CLI library can be used with all CLI implemented / enabled languages such as C#, IronPython, IronRuby, Boo, Nemerle, J#, VB.NET ().

Unnecessary package renames should be avoided. Existing package names that do not follow this policy should not be renamed until the next incompatible ABI change, at which point the new naming scheme should be used.

If the upstream software does not use major and minor number to reflect ABI stability or breaks ABI with a change in build or revision, the package must be renamed to either libfooA.B.C-cil or libfooA.B.C.D-cil (where A, B, C, D are the complete assembly version numbers), depending at which point (major or minor) the breakage occurred. All Policy Files must be dropped at this stage until a new major or minor version is released.

The upstream software may use wildcards in the assembly versions (1.2.* for example) which are filled by the compiler with a random value. You must replace these wildcards with 0 (1.2.0.0 in the example) to make it possible to use Policy Files and make predictable version numbers.

More than one library can be installed in one package but it is required that they must all have the same assembly version and belong together.

As explained above a exact match of the version number is required to load a library from the GAC. To override this behaviour and make different versions of ABI-compatible library packages really ABI-compatible you have to use . These files have to be named policy.X.Y.foo.dll (where X and Y are the major and minor number of the assembly it should be compatible with), it must be signed with the same signing key as the original assembly and it must be installed into the GAC. For information on how to create policy files look at the previous Policy Files link or at the example below.

Overriding the GAC policy should only be done when the different library versions are really ABI-compatible. This can be checked using mono-api-check of the mono-devel package. You must also raise the version in the clilibs control file to the minimum version when new interfaces/classes/methods were added.

The clilibs control file MUST be present in all GAC library packages. It can be created with the dh_makeclilibs helper script and has a format similar to the shlibs file created by and also has a similar use: it is used by dh_clideps helper script to find the correct dependencies.

You should always set the minimum required version of the library in the clilibs file.

Many libraries deliver a .pc file for use by the pkg-config helper utility, which aids other libraries and applications to link against libraries.

All GAC library packages should have a pkg-config .pc file located in /usr/lib/pkgconfig. The filename must be identical to that shipped by upstream.

When installing libraries into the GAC signing is required. The signing key should be supplied by upstream. If upstream is not supplying the key then you must use the mono.snk key from the cli-common-dev package. This key must be used for all following versions of the library to maintain ABI compatbility.

Unnecessary ABI breakages should be avoided. Existing keys shipped by the source package should not be replaced (with mono.snk) until the next incompatible ABI change.

The package should be named libfoo-cil (without a version in the package name) and libraries should not be installed into the GAC but only into /usr/lib/upstream_package_name.

Applications using non-GAC libraries must copy the libraries they need into their own application directory. You can compare this with static linking of native libraries.

When Mono code invokes an external library, it usually calls something like [DllImport("foo")] which expands "foo" to a shared library name such as "libfoo.so" which is then searched for in the library search path.

In Debian and some other binary Linux distributions, packages are split into runtime and developer (-dev) packages. Since the versioned library libfoo.so.X is usually used at runtime, and libfoo.so is a symlink only used when building against the library, the libfoo.so symlink is in the libfoo-dev package.

When packaging an application which uses libfoo.so normal users should not need the -dev packages installed just to run the application. However, Mono defaults to looking for the unversioned libfoo.so, which is unavailable in the runtime package.

When the DLL map is missing or upstream forgets to install the DLL map, it will result in a which will stop the execution of the program.

This can be fixed by creating a DLL map for the application exe or for the library DLL that is trying to invoke libfoo.so. If libfoo.so is invoked by the DLL bar.dll, create an xml file, bar.dll.config to tell Mono which .so should be loaded at runtime. bar.dll.config should be installed to the same directory as bar.dll.

<configuration> <dllmap dll="foo" target="libfoo.so.0"/> </configuration>

A config file can contain as many dllmap directives as are needed. If the upstream developer already ships a config file, but it is incomplete, you should create a patch against it in your package.

Most Mono software developers are very helpful people, and will readily accept patches to solve this type of bug if you bring it to their attention. Please be sure to inform them of all these changes.

dh_makeclilibs is used to create the clilibs control files which are used later by dh_clideps for this or other packages. It must only be used when your package contains libraries that other packages may link against.

It has the same use (and very similar parameters) to dh_makeshlibs. You should always use the most minimal version necessary.

This program must be called before dh_clideps.

See for details.

dh_clideps is used to discover the native and managed dependencies of the packages. It uses the clilibs control files, the .config of assemblies and the shlibs files created by dh_makeshlibs. The discovered dependencies are written into the ${cli:Depends} variable.

dh_shlibdeps must be run before dh_clideps. dh_makeshlibs and dh_makeclilibs must be run before dh_clideps. If not, when two binary packages from the same source package depend on one another, dh_clideps will not be able to determine the dependencies.

dh_clideps can remove duplicate dependencies created by running dh_clideps and dh_shlibsdeps when run given the -d parameter.

See for details.

dh_installcligac is used to facilitate the installation of strong-named assemblies into the various caches installed on the user's machine. Its primary purpose is to install the assemblies at the point of installation instead of pre-packing them inside the Debian package; this is also known as late-GAC install.

To identify which assemblies need to be installed into the GAC, dh_installcligac uses the debian/installcligac or the debian/packagename.installcligac to list the assemblies to install or uninstall at installation or removal respectivly.

The file format of the installcligac is simple: the full installed path of every assembly to install into the GAC. For example, the liblog4net1.2-cil package would have this in the debian/installcligac file: /usr/lib/cli/log4net-1.2/log4net.dll

dh_installcligac needs to be called after dh_install and before dh_clideps. See for details.

For binary-arch packages: binary-arch: build install ... dh_shlibdeps -a dh_makeclilibs -a -V dh_installcligac -a dh_clideps -a ... For binary-indep packages: binary-indep: build install ... dh_makeclilibs -i -V dh_installcligac -i dh_clideps -i ...

With debhelper's 7 /usr/bin/dh you don't need to add any extra commands to debian/rules yourself as debhelper has an API that allows to extend it. cli-common-dev as of version 0.5.7 can extend debhelper 7 with all commands that are needed. You can enable this by including the cli.make file in debain/rules like this: include /usr/share/cli-common/cli.make That's it, you are done! :-)

common-binary-predeb-arch common-binary-predeb-indep:: dh_shlibdeps dh_makeclilibs -V dh_installcligac dh_clideps

#!/bin/sh exec /usr/bin/cli /usr/lib/package/package.exe "$@"

You need to install following packages for this example: mono-devel libmono-sharpzip0.6-cil libmono-sharpzip0.84-cil mono-api-check /usr/lib/mono/gac/ICSharpCode.SharpZipLib/0.6.0.0__1b03e6acf1164f73/ICSharpCode.SharpZipLib.dll \ /usr/lib/mono/gac/ICSharpCode.SharpZipLib/0.84.0.0__1b03e6acf1164f73/ICSharpCode.SharpZipLib.dll CLI API Check Assembly Name: ICSharpCode.SharpZipLib Missing Interfaces: 44 Additional Interfaces: 79 The two assemblies you compared are not API compatible! You must use a new package name! The new assembly has additional interfaces. You must raise the minimal version in clilibs! The mono-api-check wrapper script checks whether there are new public/protected interfaces (where interface in this context means namespace, class, method, interface, delegate, etc) or any missing ones. When an interface is changed it will show up as missing and additional. You should follow the instructions, in this case you must create a new versioned package for the library and raise the minimal version number for the dh_makeclilibs call.

<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="foo" publicKeyToken="35e10195dab3c99f" /> <bindingRedirect oldVersion="1.2.0.0-1.2.10.0" newVersion="1.3.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration> The above example would be used for a policy file for the "foo" assembly and would tell the GAC that version 1.3.0.0 is compatible with versions 1.2.0.0 to 1.2.10.0. You have to compile and install it with al -link:policy.1.2.foo.config -out:policy.1.2.foo.dll -keyfile:path/to/keyfile gacutil /i policy.1.2.foo.dll

Keep in mind that the filenames must be policy.X.Y.foo.config and policy.X.Y.foo.dll where foo is the assembly name and X.Y is the major and minor version number you want to be compatible with.