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 on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 19805 [details]
Output showing Release|AnyCPU Build of SciChart.iOS.Charting.dll on my computer
This is a very strange error.
When compiling a Binding Library on Windows via MSBuild, the binding library DLL size is normally 8.5MBytes.
However on our build server, the binding library size is 135MBytes.
We have *no idea why*. its the same code being executed. Even the same Mac OS Server as Build agent.
Please see the attachments for more details. Any ideas why?
Created attachment 19806 [details]
Output showing Release|AnyCPU Build of SciChart.iOS.Charting.dll on the build server
This second attachment "Output showing Release|AnyCPU Build of SciChart.iOS.Charting.dll on the build server" shows the huge size of the SciChart.iOS.Charting.dll library when built on the build server
It is the *same code* being executed and the same script run. We are using the same Mac OSX server as a Mac build server. The same MS Build script. WE can't figure it out. Can you!
Hello, could you provide the Xamarin and Xamarin.iOS versions from visual studio as well as the environment information for the build server?
The easiest way to get exact version information is to use the
"Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details"
button and copy/paste the version informations (you can use the
"Copy Information" button).
For Visual Studio, use the "Help" menu, "About Microsoft Visual Studio", then find the Xamarin products in the Installed Products list.
@Andrew the most common reason for such an increase is that one build has bitcode* enabled, while the other does not have it.
Bitcode is very large (more than native code) and is, generally, added to the already present native code (for several platforms). We've seen even worse cases than the one you're describing.
However it's not possible to be sure of this without full build logs (and/or the binaries) but, giving what we have, it's the best guess I can give you today.
We solved this. It was a weird issue. Let me explain.
Our SciChart.Framework native lib was included in an SVN Repo. We did this so we could build it on OSX and as a nightly build, push it to a separate SVN Repo so that we could get this for Xamarin Windows builds.
However, the SciChart.Framework folder in SVN contains .svn folder, which was growing in size, about 70-80MBytes at last count.
We believe this was causing the large size of the SciChart.iOS.Charting.dll so we removed it. It didn't help, the binding library was still being created as 137MBytes.
I noticed however, that if I build using a different *windows* client but *same Mac OSX Server* the library size was small: 7.5MBytes.
This made me think ??! Im guessing that Xamarin Mac Build agent caches files for builds (maybe our .svn folder) on a per-client basis.
So, I re-installed Xamarin STudio and completely cleaned the OSX Build server and retried, and voila, our SciChart.iOS.Charting.dll binding library is now a respectable 7.5MBytes :)
Should we consider this to be a bug in the agent?
Hello, I don't know. Probably.
What I do know is - we have a workaround and solved the issue. It seems to be a weird edge case and solved by re-installing Xamarin Studio on OSX
Hello Andrew, if you happen to reproduce again the issue please feel free to reopen this bug report.