This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 51805 - [iOS]error MT6002: Could not strip assembly System.Net.Http.Primitives.dll while building ToDoAzure with Release|iPhone
Summary: [iOS]error MT6002: Could not strip assembly System.Net.Http.Primitives.dll wh...
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 10.4 (C9)
Hardware: PC Mac OS
: High critical
Target Milestone: (C9)
Assignee: Sebastien Pouliot
: 51670 (view as bug list)
Depends on:
Reported: 2017-01-26 22:26 UTC by GouriKumari
Modified: 2017-03-29 09:29 UTC (History)
9 users (show)

See Also:
Is this bug a regression?: Yes
Last known good build: C8SR2


Description GouriKumari 2017-01-26 22:26:54 UTC
## Steps to reproduce:

Update System to Xamarin.iOS cycle9 mtouch (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
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-01-27 06:28:28 UTC
@Sebastien, this looks related to (or a duplicate of) bug #51805 (but that bug doesn't have a test case).
Comment 3 Sebastien Pouliot 2017-01-27 14:29:13 UTC
*** Bug 51670 has been marked as a duplicate of this bug. ***
Comment 4 dhaligas 2017-01-27 15:06:53 UTC
@sebastien thanks! I am glad we found a test case.  This is blocking us from using cycle 9
Comment 5 Jb Evain 2017-01-27 16:10:52 UTC
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.
Comment 6 dhaligas 2017-01-27 16:26:39 UTC
@jb this is the nuget package that is comes from
Comment 8 Sebastien Pouliot 2017-01-30 19:43:18 UTC
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.
Comment 9 dhaligas 2017-01-30 19:52:08 UTC
@sebastian good to know you can repo.  This works in Stable so what changed from stable to RC?
Comment 10 Philipp Sumi 2017-01-31 00:52:07 UTC
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?
Comment 11 Sebastien Pouliot 2017-01-31 03:20:19 UTC
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 [1]) 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 [1].

[1] The scope of exported types cannot be updated [1]. @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.

Comment 12 Jb Evain 2017-01-31 14:34:53 UTC
@Sebastien, no reason for [1], just an oversight. I'll add the setter.
Comment 13 Sebastien Pouliot 2017-01-31 15:09:42 UTC
@JB thanks!

Fixed in cycle9 with

Fix for master postponed until we resolve some issues with the bots after the update to the latest Sierra.
Comment 14 Jb Evain 2017-01-31 17:45:38 UTC
@Sebastien, added setter in:
Comment 15 Naqeeb 2017-01-31 17:53:27 UTC
*****Reproduce Staus:*****
I have tried to reproduce this issue with build xamarin.ios-  and able to reproduce successfully. Here is the screencast for the same:

*****Verified Status:*****
I have checked this issue with latest C9 build i.e. xamarin.ios-  and observed that it is working fine. Here is the screencast for the same:

Environment info:

I will verify once when fix with master build.

Comment 16 Sebastien Pouliot 2017-01-31 19:57:39 UTC
master PR
Comment 18 Danish Akhtar 2017-02-01 07:05:19 UTC
I have checked this issue with latest master X.iOS, 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:

Hence closing this issue.

Comment 19 Philipp Sumi 2017-02-01 10:55:50 UTC
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.
Comment 20 Sebastien Pouliot 2017-02-03 14:21:53 UTC
The existing fix caused a regression [1] when reflection is used (and this happens when serializing data, e.g. TimeZoneInfo) so it's being reverted.

Comment 21 dhaligas 2017-02-03 17:01:03 UTC
@sebastien can you add me to 51287 so I can watch the progress?
Comment 22 Sebastien Pouliot 2017-02-03 17:06:43 UTC
@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 [1]

Comment 23 dhaligas 2017-02-03 17:46:50 UTC
@sebastian so it will be good to go then?
Comment 26 Sebastien Pouliot 2017-02-03 21:32:29 UTC
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:
Comment 27 GouriKumari 2017-02-06 15:14:08 UTC
Verified with Xamarin.iOS cycle9 build mtouch (cycle9: 22d559f). Sample app build successfully with Release|iPhone config.

## Logs:
Build Log:
Comment 28 Seifer 2017-03-28 17:03:36 UTC
Is there a workaround while we are waiting for the fix be available in Visual Studio for Mac?
Comment 29 Rolf Bjarne Kvinge [MSFT] 2017-03-29 08:42:05 UTC
@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)?
Comment 30 Seifer 2017-03-29 09:23:35 UTC
Hi, @Rolf. Thank for getting back on this.

In short:
- issue solved after I've downloaded Visual Studio for Mac installer and updated Xamarin.iOS part from the installer.

In details:
- I had installed Xamarin.iOS
- I expected Visual Studio "Check for Updates ..." should already work. Which seems doesn't work yet
- Now I have Xamarin.iOS installed

Of topic:
- When is it expected Visual Studio for Mac supports built-in updates?
Comment 31 Rolf Bjarne Kvinge [MSFT] 2017-03-29 09:29:19 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.