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.
Cecil writes the full path to the .pdb is embedded into assemblies.
At build time, we build 32-bit and 64-bit assemblies in different directories, which means that the resulting linked assemblies end up with different .pdb paths:
> diff -u a b
--- a 2017-04-06 09:33:53.000000000 +0200
+++ b 2017-04-06 09:34:05.000000000 +0200
@@ -48445,7 +48445,7 @@
000cdcb0 63 68 54 6f 6f 6c 2e 43 72 65 61 74 65 54 65 6d |chTool.CreateTem|
000cdcc0 70 6f 72 61 72 79 44 69 72 65 63 74 6f 72 79 30 |poraryDirectory0|
000cdcd0 2f 6d 74 6f 75 63 68 2d 74 65 73 74 2d 63 61 63 |/mtouch-test-cac|
-000cdce0 68 65 2f 33 32 2f 50 72 65 42 75 69 6c 64 2f 6d |he/32/PreBuild/m|
+000cdce0 68 65 2f 36 34 2f 50 72 65 42 75 69 6c 64 2f 6d |he/64/PreBuild/m|
000cdcf0 73 63 6f 72 6c 69 62 2e 70 64 62 00 24 fb 0c 00 |scorlib.pdb.$...|
000cdd00 00 00 00 00 00 00 00 00 3e fb 0c 00 00 20 00 00 |........>.... ..|
000cdd10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
which prevents us from putting a single assembly into the .app instead of a 32-bit and a 64-bit version.
I think the best fix is for Cecil to support writing relative paths here: https://github.com/jbevain/cecil/blob/7297b51/Mono.Cecil.Cil/PortablePdb.cs#L304
Another option is to change our assembly-comparing code to ignore these differences. I don't like this though, since it's making complicated code even more complicated.
For reference, Roslyn has a similar problem: https://github.com/dotnet/roslyn/issues/9813 (this would affect non-linked builds, and assemblies not processed by Cecil).
This affects release builds as well, because we always copy and load any pdb files so that the AOT compiler can generate better native debug symbols.
Cecil bug: https://github.com/jbevain/cecil/issues/372
Unit test: https://github.com/rolfbjarne/xamarin-macios/commit/5189c82627ad017c6ff87ab8141b172ca9376022
This can have a significant impact on the final application size.
@Rolf, are assemblies in this case built with -deterministic? If so, Cecil could use this to decide whether to write a full path or a relative path.
@JBEvain, unlikely, since it's a fairly new flag. And in any case we don't build our own assemblies with -deterministic yet.
Ok so you need a way to set this behavior unconditionally. I'll look into it.
@Manuel this, in particular the roslyn option, might be of interest wrt debugging the BCL
Looking into this on our iOS side.
@Marek can you pick up https://github.com/jbevain/cecil/commit/f980e1ff78049036312f6709861a19501e14c576 inside mono fork so we can bump and close this ? thanks!
master PR: https://github.com/xamarin/xamarin-macios/pull/2026
d15-2 PR: https://github.com/xamarin/xamarin-macios/pull/2027
Merged in master https://github.com/xamarin/xamarin-macios/commit/bb288e8c600dad55775a02400987fdbe1697c6a7
Merged in d15-2 https://github.com/xamarin/xamarin-macios/commit/733ddcf0fb258b7fdf9dc6a9b632e8cb3a113f3f
Hi Rolf, this is unit testing bug, Can you please verify this at your end??
The unit test is green, so this is verified.