Mkbundle Mono binding redirection
I have a sample .NET application that works fine on windows and my Ubuntu environment is using mono.
I'm trying to use Mkbundle to create a single prefab build, so I can docker containerize it with busybox and keep the size small instead of the usually huge bloated containers.
The problem I am having is with Json.net, I think due to the redirection of the assembly binding from the app.config file, has anyone else come across this?
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.1" /></startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
And it creates the following error with and without -static
source to share
The way I got around this is 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.
Then you will need to specify any missing dependencies manually (I know it kind of stinks)
mkbundle --nodeps -o console OutsideSourcesAPI.exe *.dll mscorlib.dll System.Xml.dll
source to share
Slightly late answer, but I had the same problems and was not enough to do it, as I wanted to bind Mono's static time statically (using the --static option). This is because there are no GAC assemblies that skip -skip-scan and / or -nodeps, including any transitive dependencies they may have. Of course, this only affects machines without Mono installed (it will still use the Mono GAC if the machine has one), which also makes testing difficult.
The supply of -skip-scan and -nodeps means that you need to provide the DLL list yourself (bypassing the mkbundle build scanner), allowing you to either do this manually, or write your own scanner that I made that collects every single build, including in .NET platform. I didn't want to list each individual assembly by hand, and if I miss one I have runtime errors. With this I was able to work around the assembly binding problems app.config as well.
source to share
Adding the -skip-scan flag seems to fix the problem without having to resort to --nodeps and a manual DLL dependency list.
mkbundle -z --deps --skip-scan MyApp.exe
Note that as with mono 4.2.3, mkbundle prefers mono-distribution assemblies to assemblies in the local folder. This can cause problems if you have a naming clash between the local assembly and the framework assembly (probably a candidate for System.Web.Http.dll).
You can work around this by specifying a local build of assemblies on the command line with a prefix. /
mkbundle -z --deps --skip-scan MyApp.exe ./System.Web.Http.dll
This second issue seems to be resolved in newer versions of mono.
source to share