Mkbundle Mono Assembly binding redirection Mkbundle Mono Assembly binding redirection docker docker

Mkbundle Mono Assembly binding redirection


How I got around it was to specify the --nodeps flag.

mkbundle --nodeps -o console OutsideSourcesAPI.exe *.dll

However, when you run it, it may give you errors like...

The assembly mscorlib.dll was not found or could not be loaded.

or

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Xml, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes' or one of its dependencies.

You'll then have to specify any missing dependencies manually (I know, kinda of stinks)

mkbundle --nodeps -o console OutsideSourcesAPI.exe *.dll mscorlib.dll System.Xml.dll


A bit of a late answer but had the same issues and just doing this wasn't enough since I wanted to link the Mono runtime statically (using the --static option). This is due to the missing GAC assemblies that --skip-scan and/or --nodeps misses including any transitive dependencies these may have. Of course this only affects machines without Mono installed (it will still use Mono's GAC if it is there on the machine) making it harder to test as well.

Supplying -skip-scan and -nodeps means you need to supply the DLL list yourself (bypassing the mkbundle assembly scanner) allowing you to either do this manually or write your own scanner which I did that picks up every single assembly including those in the .NET framework. I didn't want to list every single assembly by hand and if I miss one have runtime errors. With this I was able to get around the app.config assembly binding issues as well.


Adding the --skip-scan flag seems to fix the problem without having to resort to --nodeps and a manual list of dependency dlls.

mkbundle -z --deps --skip-scan MyApp.exe

Note that as of mono 4.2.3, mkbundle seems to prefer assemblies in the mono distribution to assemblies in the local folder. This can cause problems if you have a naming clash between a local assembly and a framework assembly (System.Web.Http.dll is likely candidate).

You can work around this by specifying the clashing local assembly on the command line with a ./ prefix

mkbundle -z --deps --skip-scan MyApp.exe ./System.Web.Http.dll

This second problem appears to be resolved in newer versions of mono.