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.
## Steps to reproduce:
Update System to Xamarin.iOS cycle9 mtouch 10.4.0.97 (cycle9: 2bcf787) and build Xamarin.Forms sample ToDoAzure.iOS with Release|iPhone config.
## Actual Behaviour
App fails to build with error MT6002: Could not strip assembly `/Users/xamarinqa/QABot/builder/data/lanes/4024/9975cb17/source/xamarin-forms-samples/WebServices/TodoAzureAuthADB2CServerFlow/iOS/obj/iPhone/Release/mtouch-cache/64/Build/System.Net.Http.Primitives.dll`.
## Supplemental Info:
This issue seems to occur after bump https://github.com/xamarin/xamarin-macios/commit/caf562b65961204eef02111dc91763d92588682b
@Sebastien, this looks related to (or a duplicate of) bug #51805 (but that bug doesn't have a test case).
*** Bug 51670 has been marked as a duplicate of this bug. ***
@sebastien thanks! I am glad we found a test case. This is blocking us from using cycle 9
I had a look using the binaries uploaded in #51670.
It appears that the assembly given as input of the cil-stripper contains invalid metadata constructs. Namely, it has 3 exported types (type forwarders), and their metadata scope are pointing to an AssemblyRef row that doesn't exist.
The root cause of the issue must happen one step before calling cil-strip, so the issue likely lies in either the handling of type forwarders by the linker, or in the Cecil version used by the linker.
@jb this is the nuget package that is comes from
The unusual bit is that System.Net.Http.Primitives.dll has type forwarders to System.Net.Primitives.dll which then forwards, again the same types to System.dll
I can duplicate the issue as described.
@sebastian good to know you can repo. This works in Stable so what changed from stable to RC?
If I switch the linker behavior to "Link All", the error goes away. Is there anything we should be worried about when using that option?
a. System.Net.Http.Primitives.dll is user code *and* contains type forwarders (it's like a facade) to another facade assembly, System.Net.Primitives.dll, that ships with the SDK;
b. The former, System.Net.Http.Primitives.dll, is not processed by the linker, e.g. no code is removed and the assembly cannot be deleted. However we save back (as much as we can ) the result of any type being resolved;
c. It also means the later, System.Net.Primitives.dll, is fully linked and (in many cases) can be removed from the final application (as it's mostly forwarders).
d. This means the final, re-saved, System.Net.Http.Primitives.dll binary could point to non-existing metadata, i.e. the removed System.Net.Primitives.dll, because of .
 The scope of exported types cannot be updated . @JB any reason for this ?
Because we resolve (and save) the forwarders *and* because we do not allow code downloads or generation (Apple restriction) it is possible to remove the forwarders, which will fix the issue for XI.
@Sebastien, no reason for , just an oversight. I'll add the setter.
Fixed in cycle9 with
Fix for master postponed until we resolve some issues with the bots after the update to the latest Sierra.
@Sebastien, added setter in:
I have tried to reproduce this issue with build xamarin.ios-10.4.0.97_2bcf787f0545d985d84c74c9c98cd7a55bd69d91 and able to reproduce successfully. Here is the screencast for the same: https://www.screencast.com/t/Bi5M4kTGi
I have checked this issue with latest C9 build i.e. xamarin.ios-10.4.0.101 and observed that it is working fine. Here is the screencast for the same: https://www.screencast.com/t/O4XCkAsNgoGK
Environment info: https://gist.github.com/NaqeebAnsari/96b2858920b54cf29657e74ab1bb12d9
I will verify once when fix with master build.
master PR https://github.com/xamarin/xamarin-macios/pull/1600
Fixed in master https://github.com/xamarin/xamarin-macios/commit/c633bd378fffc243060d7809b0e1d92a7c5887b3
I have checked this issue with latest master X.iOS 10.5.0.417, observed that now this issue doesn't exists.
I am successfully able to build Xamarin.Forms sample ToDoAzure.iOS with Release|iPhone config. Here is the screencast for the same: https://www.screencast.com/t/mt1f0dVmXn
Hence closing this issue.
Since we're having this issue now: Would a --linkskip System.Http.Primitives do the job or cause issues on certain platforms? It seems to be ok on my iPhone 6 with the "Link SDKs only" option.
The existing fix caused a regression  when reflection is used (and this happens when serializing data, e.g. TimeZoneInfo) so it's being reverted.
@sebastien can you add me to 51287 so I can watch the progress?
@dhaligas it's only internal links to failing unit tests and there won't be progress beside marking it fixed once I revert PR1600.
This will happen as soon I can bump mono (and cecil) with the correct fix 
@sebastian so it will be good to go then?
cycle9 PR https://github.com/xamarin/xamarin-macios/pull/1639
master PR https://github.com/xamarin/xamarin-macios/pull/1640
cycle9 fixed in https://github.com/xamarin/xamarin-macios/commit/22d559f44c3e083271ad09c8b6cbbea543fb2e31
master fixed in https://github.com/xamarin/xamarin-macios/commit/a94e4dc423c7b55811340ccecd58beaedb6af03a
PSA in case someone on c.c. wants to check/confirm the fix before it gets released next week, we do publish all our `cycle9` builds. You can get them from
direct link: https://bosstoragemirror.blob.core.windows.net/wrench/macios-mac-cycle9/22/22d559f44c3e083271ad09c8b6cbbea543fb2e31/xamarin.ios-10.4.0.114.pkg
Verified with Xamarin.iOS cycle9 build mtouch 10.4.0.114 (cycle9: 22d559f). Sample app build successfully with Release|iPhone config.
Build Log: https://gist.github.com/GouriKumari/b3f2943c8b8126e02948462e952f4971
Is there a workaround while we are waiting for the fix be available in Visual Studio for Mac?
@Seifer, you should already have this fix. Can you get your complete version information (in the About menu, click on "Show Details" and paste everything here)?
Hi, @Rolf. Thank for getting back on this.
- issue solved after I've downloaded Visual Studio for Mac installer and updated Xamarin.iOS part from the installer.
- I had installed Xamarin.iOS 10.4.0.97
- I expected Visual Studio "Check for Updates ..." should already work. Which seems doesn't work yet
- Now I have Xamarin.iOS 10.4.0.128 installed
- When is it expected Visual Studio for Mac supports built-in updates?
(In reply to Seifer from comment #30)
> Off topic:
> - When is it expected Visual Studio for Mac supports built-in updates?
I might be wrong here (I work for a different team), but my guess is when it becomes more than just a preview. Since VS for Mac is not shipped through the normal channels, making "Check for updates..." work would probably make VS for Mac uninstall itself otherwise.