Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 15295 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 5095 [details]
Test case project with Fiddler Screenshots
A simple HttpListener application works correctly on regular mono runtime but behaves differently when compiled with mkbundle on mono 3.2.3 Windows.
On mkbundle-d version EVERY http response is "cutting" the first 3 characters of the response on the mkbundle-d sample.
The regular mono TestHttpListener.exe works 100% correctly instead.
Attached a simple test case.
export CC="i686-pc-mingw32-gcc -U _WIN32"
mkbundle --deps TestHttpListener.exe -o TestHttpListener_AOT.exe
Created attachment 5098 [details]
Found the problem, only happens if libmonoboehm-2.0.dll or libmonosgen-2.0.dll in current dir
The problem only happens if libmonoboehm-2.0.dll or libmonosgen-2.0.dll (Tried both GC) is in current directory as the mkbundled .exe.
If one removes those lib*.dll and sets $PATH correctly pointing to a working mono 3.2.3 install, the problem disappears.
If it can help, the non-working case outputs charset=utf8 instead of charset=Windows-1252.
Is there any .config file that mono expects in current directory, or relative path that controls this different behaviors?
Solved it by trial and guess.
Just force the bundling of I18N.dll and I18N.West.dll in the bundle.
Is mkbundle supposed to include those dlls automatically or is it a programmer duty to actually 'know' assemblies that may be needed by the runtime?
Not sure if to mark this as "bug" since now on.
I just wanted to add that I was having the exact same issue, and it wasn't resolved by adding only the two DLLs mentioned previously, but adding all of the following to my mkbundle line fixes it:
I18N.dll I18N.CJK.dll I18N.MidEast.dll I18N.Other.dll I18N.Rare.dll I18N.West.dll