|Summary:||Mono CIL Stripper error on Index is less than 0 or more than or equal to the list count.|
|Product:||Visual Studio Extensions||Reporter:||Prashant Cholachagudda <prchol>|
|Severity:||normal||CC:||brendan.zagaeski, chrisntr, ggirard, Ian.Ceicys, joe, joj, kzu, mono-bugs+bugzilla, owen.stewart, paul, sunilk|
|Tags:||Is this bug a regression?:||---|
|Last known good build:|
|Bug Depends on:||31009|
|Attachments:||Thoroughly minimized test case|
Description Prashant Cholachagudda 2014-12-12 13:10:03 UTC
The build error happens on mtbs only when linking is enabled (Link SDK Only). An exception occurs at link time on the MTBS side and the connection to the build machine from VS is closed without any error messages. We don't see any build error if linker is disabled. # Version Information ## Windows Box VS 2013 update 4 Xamarin for Visual Studio 184.108.40.206 Xamarin.iOS 220.127.116.11 Xamarin.Android 18.104.22.168 ## Mac Xamarin.iOS 22.214.171.124 Sample code and logs in private comment.
Comment 2 Sunil Kumar 2014-12-30 12:11:24 UTC
I have tried to reproduce this issue. I downloaded the attached sample project from link given in comment 1. I tried to open this sample project using VS and getting some warning popups, after that if I builds this project then it gives builds errors. Here is the screencast for the same: http://screencast.com/t/xZIijldF93 Please let me know how can I reproduce this issue. Environment info: Microsoft Visual Studio Professional 2013 Version 12.0.31101.00 Update 4 Microsoft .NET Framework Version 4.5.50938 Xamarin 126.96.36.199 (10cfd178d55287f09c85f5a1e604dfe20889a40f) Xamarin.Android 188.8.131.52 (ba9bbbdd44cfdc4bf485e8885bd2ad24fba525f7) Xamarin.iOS 184.108.40.206 (840a925103a0bf4a856507f13d5eaee3c1579c2f)
Comment 3 Guillaume 2014-12-30 13:36:49 UTC
The errors you seen only appears on the first build, rebuilding the solution clean them. We have never figured out why... The reproduce the issue, you have to: - Set the project Distech.X50.UI.Touch as the startup project - Select the build config Release/iPhone - Choose a valid development device - Change the signing identity in project settings to Automatic (it has been forced due to an issue fixed since 220.127.116.11 due to Apple provisioning profile renaming and is no longer required) - Start a debug session I also made a screencast of how to reproduce: http://screencast.com/t/UwtGfaR3nyJD As a side note, even if the issue is reproduced in this screencast with an MTBS running in a VM, our build server which use an MTBS running on a Mac Mini is impacted by the same effect.
Comment 5 Brendan Zagaeski (Xamarin Support) 2015-01-30 13:23:18 UTC
Thanks for the extra details! I was able to reproduce the problem following the steps in comment 3. I'll add a little note here to surface the error message that appears in the project build log on the build host (~/Library/Logs/Xamarin/MonoTouchVS/*UITouch*.log): > Stripping assembly /Users/admin/Library/Caches/Xamarin/mtbs/builds/UITouch/aa623b68d1bca03f0a501ebee0543689/obj/iPhone/Release/mtouch-cache/Build/Cirrious.MvvmCross.Binding.dll > /Library/Frameworks/Mono.framework/Versions/Current/bin/mono > /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/mono-cil-strip.exe > /Users/admin/Library/Caches/Xamarin/mtbs/builds/UITouch/aa623b68d1bca03f0a501ebee0543689/obj/iPhone/Release/mtouch-cache/Build/Cirrious.MvvmCross.Binding.dll > bin/iPhone/Release/UITouch.app/Cirrious.MvvmCross.Binding.dll > Mono CIL Stripper > > Error: System.ArgumentOutOfRangeException: Index is less than 0 or more than or equal to the list count. > Parameter name: index ## Corresponding error from the diagnostic build output (`buildLog.txt`) > Executing task: Xamarin.iOS.Tasks.MTouchTask (TaskId:954) > Server returned an error. The underlying connection was closed: The connection was closed unexpectedly. > (TaskId:954) > Remote task execution failed. (TaskId:954) > MTouchTask: 2014-12-01T10:39:37.5981734-05:00 - Finished (TaskId:954) ## There doesn't appear to be any corresponding error in `mtbserver.log` ## My version info ### Windows 8.1 64-bit, in VMWare Fusion 6.0.5 (2209127) Microsoft Visual Studio Professional 2013 Version 12.0.30723.00 Update 3 Microsoft .NET Framework Version 4.5.51641 Xamarin 3.9.289.0 (39a70ae) Xamarin.Android 18.104.22.168 (49a04b966feb40dfdba49d57ba16249b66d606a6) Xamarin.iOS 22.214.171.124 (3b3ef438017c7ecf486defa9e01567a5f2b3cb2a) ### OS X 10.9.5, MacBook Air Xamarin.iOS 126.96.36.199 (Business Edition) Hash: 3b3ef43 Build date: 2015-01-24 09:42:21-0500 Xcode 6.1 (6604), Build 6A1052d
Comment 7 Brendan Zagaeski (Xamarin Support) 2015-04-01 00:31:26 UTC
Created attachment 10580 [details] Thoroughly minimized test case I was able to recreate the problem from scratch in a new project. The new test case contains 2 projects: an iOS app project and a VB.NET PCL project. (Note for future reference for any customers who happen to read this bug: minimizing the test case will often accelerate the bug fixing process or reveal workarounds during the minimization process.) ## Workaround? It seems that the failure during `mono-cil-strip` is non-fatal? If you change the "Additional mtouch arguments" in this new test case (or in the original test case) so that that field contains just one "-v" (or is empty), the `mono-cil-strip` command will still fail, but the project will build successfully. The original test app built and launched successfully in the iPhone|Release configuration after I removed the "Additional mtouch arguments". (Beware of bug 26308 when adjusting this setting via the project properties. You'll need to manually re-select "Link SDK assemblies only" each time you open the properties to ensure the correct linker setting is maintained.) ## New test case - The iOS app project references the VB.NET PCL project, and just instantiates the 1 class contained in the VB.NET PCL project: `var x = new VBClassLibrary1.Class1();` - The VB.NET PCL project contains 1 tiny class: > Public Class Class1 > Dim X = System.Net.DecompressionMethods.Deflate > Dim Y As System.Net.IWebProxy > Dim Z As System.Net.TransportContext > End Class ## Additional discussion I found that the assembly that fails during stripping is actually `System.Net.Http.Primitives.dll`: > /Library/Frameworks/Mono.framework/Versions/Current/bin/mono > /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/mono-cil-strip.exe > /Volumes/Cases/macuser/Library/Caches/Xamarin/mtbs/builds/DistechX50UITouch/16bb8d380a7b277972e5afebc62a34be/obj/iPhone/Release/mtouch-cache/Build/System.Net.Http.Primitives.dll > /Volumes/Cases/macuser/Library/Caches/Xamarin/mtbs/builds/DistechX50UITouch/16bb8d380a7b277972e5afebc62a34be/bin/iPhone/Release/DistechX50UITouch.app/System.Net.Http.Primitives.dll'' It seems that the `System.Net.Http.Primitives.dll` that gets copied into the `Build` folder from the `PreBuild` folder is somehow invalid. The version of `System.Net.Http.Primitives.dll` that's in the "Link" folder  (before linking) is roughly 21 KB. >  /Volumes/Cases/macuser/Library/Caches/Xamarin/mtbs/builds/DistechX50UITouch/16bb8d380a7b277972e5afebc62a34be/obj/iPhone/Release/mtouch-cache/Link/System.Net.Http.Primitives.dll After the linker adjusts this file (to fix up the IL offsets maybe?), it places a new version in the "PreBuild" folder that is only 5 kb. This all seems a bit curious. `System.Net.Http.Primitives.dll` looks like it might be a facade assembly, so I'm not sure that it's supposed to be in the app bundle at all?
Comment 8 Brendan Zagaeski (Xamarin Support) 2015-04-01 03:56:55 UTC
Comment 9 Paul Johnson 2015-04-19 06:42:39 UTC
I'm seeing this bug with the current stable release === Xamarin Studio === Version 5.9 (build 427) Installation UUID: f3d1a29c-1ba2-4a83-a193-1087efe91a85 Runtime: Mono 4.0.0 ((detached/d136b79) GTK+ 2.24.23 (Raleigh theme) Package version: 400000143 === Xamarin.Android === Version: 188.8.131.52 (Business Edition) Android SDK: /Users/PFJ/Library/Developer/Xamarin/android-sdk-mac_x86 Supported Android versions: 2.3 (API level 10) 4.0.3 (API level 15) 4.1 (API level 16) 4.2 (API level 17) 4.3 (API level 18) 4.4 (API level 19) 4.4.87 (API level 20) 5.0 (API level 21) Java SDK: /usr java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) === Xamarin Android Player === Version: Unknown version Location: /Applications/Xamarin Android Player.app === Apple Developer Tools === Xcode 6.3 (7569) Build 6D570 === Xamarin.iOS === Version: 184.108.40.206 (Business Edition) Hash: f7736a4 Branch: Build date: 2015-04-09 04:22:08-0400 === Xamarin.Mac === Version: 220.127.116.118 (Business Edition) === Build Information === Release ID: 509000427 Git revision: 04666fd43a57b4782529cad9723ce1f54926fe6c Build date: 2015-04-14 18:06:43-04 Xamarin addins: 791954691dfbc403676a103e52a0bb9754b9af29 === Operating System === Mac OS X 10.10.4 Darwin Pauls-iMac.local 14.3.0 Darwin Kernel Version 14.3.0 Wed Apr 8 03:17:44 PDT 2015 root:xnu-2782.20.48~13/RELEASE_X86_64 x86_64
Comment 10 Paul Johnson 2015-04-19 06:46:49 UTC
adding -v when building for the app store doesn't let it build to create an archive. works fine though for debug
Comment 11 Paul Johnson 2015-04-19 09:47:44 UTC
Reverting to the previous version of mono solves the problem for me (the version of mono touch makes no difference - having it on stable with the alpha version of mono still shows the issue)
Comment 12 Brendan Zagaeski (Xamarin Support) 2015-04-20 19:12:48 UTC
@Paul Johnson, thanks for the report. Based on the symptoms you're describing, I think you might be hitting a closely related but distinct bug. I would recommend filing a separate bug report for the issue you're seeing, being sure to include a zipped up test case that demonstrates that specific problem. Feel free to add a link to this bug (bug 25344) in the new report, and also feel free to add a link to the new report on this page. ## Other updates The fixes for bug 28617 (as mentioned in comment 8) are included in the current Alpha/Beta versions (XamarinVS 3.11, Xamarin.iOS 8.10, Mono 4.0). Those fixes stop the problem in my minimized test case from comment 7 (see also the "Version information" below). So I suspect this bug is in fact a duplicate of bug 28617. Unfortunately there is a second (I think unrelated) regression in Xamarin.iOS 8.10 (Bug 29256) exposed by the original full test case (from private comment 1). That second bug is currently blocking me from verifying whether the fix for bug 28617 solves the problem for the original test case. So I will leave this bug (bug 25344) open for now. Once bug 29256 is fixed, I will test the original full test case once more to verify that it builds without error. ## Version information ### Windows 8.1 64-bit, in VMWare Fusion 6.0.5 (2209127) Microsoft Visual Studio Professional 2013 Version 12.0.30723.00 Update 3 Xamarin 3.11.431.0 (3673cfb) Xamarin.iOS 18.104.22.168 (7741cc495ab0baf04ff0405d0604bc27f0ecae2e) ### OS X 10.9.5, MacBook Air Xamarin.iOS, 22.214.171.1248 (Business Edition) Hash: c2c0012 Branch: master Build date: 2015-04-14 17:26:21-0400 Mono 4.0.0 (detached/d136b79) Xcode 6.2 (6776), Build 6C131e
Comment 13 Brendan Zagaeski (Xamarin Support) 2015-06-12 15:57:23 UTC
Comment 14 Joaquin Jares 2015-10-06 16:13:53 UTC
@Brendan 31009 is now verified -> fixed. Can you retest this? Marking as fixed for retesting.
Comment 15 Brendan Zagaeski (Xamarin Support) 2015-10-20 01:40:26 UTC
## Final verification of the test case from private comment 1. Verified. I have now verified that the original full test case for this bug builds without error as of "Cycle 5 – Service Release 2" Stable. As it turned out, the final Stable build of "Cycle 5 – Service Release 2" somehow stopped the particular cause of Bug 31009 in the test case from private comment 1 (I had tested with Alpha or Beta versions in comment 13). The build completes without error in the "Release|iPhone" configuration following the exact steps to reproduce from comment 3. ### Windows 8.1 64-bit, in VMWare Fusion 6.0.6 XamarinVS 3.11.666.0 (ebae43a) ### OS X 10.9.5, MacBook Air Xamarin.iOS 126.96.36.199 (ef8c2f7) Mono 4.0.2 (detached/c99aa0c) Xcode 6.3.2, Build version 6D2105 ## Also verified on Cycle 6 RC 0 For good measure, I also checked the test case from private comment 1 on the current Alpha version "Cycle 6 – Release Candidate 0". Again it built without error.