Bug 56808 - Cannot debug referenced iOS Class library in Visual Studio 2015/2017
Summary: Cannot debug referenced iOS Class library in Visual Studio 2015/2017
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 10.10 (d15-2)
Hardware: PC Windows
: High critical
Target Milestone: 15.3
Assignee: Rolf Bjarne Kvinge [MSFT]
: 56893 57483 ()
Depends on:
Reported: 2017-05-24 15:23 UTC by Christian.Wall
Modified: 2017-07-29 20:15 UTC (History)
16 users (show)

Is this bug a regression?: Yes
Last known good build: Xamarin.iOS (d15-1: a04678c2)

Sample Project that shows the bug (14.00 KB, application/x-zip-compressed)
2017-05-24 15:23 UTC, Christian.Wall
Test case for Mac, with precompiled "bad" class library (21.17 KB, application/zip)
2017-06-08 00:51 UTC, Brendan Zagaeski (Xamarin Team, assistant)

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Christian.Wall 2017-05-24 15:23:04 UTC
Created attachment 22428 [details]
Sample Project that shows the bug

Hi Xamarin-Team,

we found the following bug:
Breakpoints set in classes that are placed in a class library not hitting if the class library contains a BundleResource.
As soon as you remove the BundleResource from the class library you Can step into the class library classes.

I attached a Sample Solution which contains the App (App1) and a Class library (ClassLibrary1). In the class library you find the class "Class1" that contains one method "Test". There is also a zip file included in the class library as a BundleResource.

Now when you launch the app in debug mode on a device you can't step into the method "Test" (also breakpoints in that method won't hit). The method will be called from within AppDelegate.FinishedLaunching.

If you set the Build Action on the zip file to None you Can step in to the method "Test".

Comment 1 Christian.Wall 2017-05-29 06:38:35 UTC
Detailed Version Infos:

Microsoft Visual Studio Enterprise 2017 
Version 15.2 (26430.6) Release
Microsoft .NET Framework
Version 4.7.02046

Xamarin (c871575)
Xamarin.Android SDK (448f54f)
Xamarin.iOS and Xamarin.Mac SDK (30b6e87)
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2017-06-01 02:46:19 UTC
## Note to the Xamarin team

As on Bug 56893:

- The debug symbols work as expected on iOS simulator, but fail on iOS device.

- Changing the DebugType of the iOS class library project to "portable" in the test case attached in Comment 0 was an effective workaround in my test environment.

Perhaps this indicates that both bugs can be resolved by a single fix.

## Confirmation status: confirmed on Xamarin "15.2.2 release"

> BAD:  XamarinVS (1be4f0c) + Xamarin.iOS (d15-2: d2270eec) "15.2.2 release"
> BAD:  XamarinVS (c871575) + Xamarin.iOS (d15-2: 3e5ac5ff) "15.2   release"

## Additional testing environment info (brief)

### Windows

Microsoft Visual Studio Enterprise 2015
Version 14.0.25431.01 Update 3

Microsoft .NET Framework
Version 4.7.02046

Windows 10 version 1703 (OS Build 15063.296)
US English locale, US Eastern time zone

### Mac

Mono (2017-02/5077205)

Xcode 8.3, Build version 8E162
macOS 10.12.4
US English locale, US Eastern time zone

### Devices

iPad Mini 2, iOS 8.0
Comment 3 Jeff Gonzales 2017-06-05 20:24:35 UTC
My solution has multiple projects.  I changed the project containing the breakpoints to "portable" and it seems to be working for now.  Must I do this for every project in my solution?

What is the root cause of this?  When will a permanent fix be available?
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2017-06-08 00:51:44 UTC
Created attachment 22760 [details]
Test case for Mac, with precompiled "bad" class library

## Note to the Xamarin.iOS team

In case it might be convenient for further testing by the Xamarin.iOS team, here is a test case to replicate the problem directly on Mac by using a pre-compiled "bad" library for the iOS class library.

### Regression status: regression in Xamarin.iOS 10.10 compared to 10.8

BAD:  Xamarin.iOS (d15-2: d2270eec)
GOOD: Xamarin.iOS (d15-1: a04678c2)

### Steps to replicate

1. Unzip the test case.

2. Build the project in the "Debug|iPhone" configuration:
msbuild /t:Build /p:Configuration=Debug /p:Platform=iPhone SingleViewIphone1.sln

(The "badlib" directory in the attached test case contains a pre-compiled version of the iOS class library _with_ a bundle resource.  The "goodlib" directory contains the same class library compiled _without_ the bundle resource.)

### BAD Results

The IosClassLibrary1.dll.mdb file is present as expected in the "mtouch-cache/Link" directory, but it is _missing_ from the "mtouch-cache/PreBuild" directory:

> $ ls SingleViewIphone1/obj/iPhone/Debug/device-builds/*/mtouch-cache/Link/IosClassLibrary1.dll.mdb
> SingleViewIphone1/obj/iPhone/Debug/device-builds/ipad4.4-8.0/mtouch-cache/Link/IosClassLibrary1.dll.mdb

> $ ls SingleViewIphone1/obj/iPhone/Debug/device-builds/*/mtouch-cache/PreBuild/IosClassLibrary1.dll.mdb
> ls: SingleViewIphone1/obj/iPhone/Debug/device-builds/*/mtouch-cache/PreBuild/IosClassLibrary1.dll.mdb: No such file or directory

It seems that maybe the `LinkAssemblies()` method [1] is silently failing to output the IosClassLibrary1.dll.mdb file into the PreBuild directory as expected?

[1] https://github.com/xamarin/xamarin-macios/blob/e36d1b060f8417ede929c838c3a63dddd579860a/tools/mtouch/Target.cs#L512

### Additional testing environment info

Mono (2017-02/5077205)

Xcode 8.3, Build version 8E162
macOS 10.12.4
US English locale, US Eastern time zone
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2017-06-08 02:28:05 UTC
*** Bug 56893 has been marked as a duplicate of this bug. ***
Comment 7 Rolf Bjarne Kvinge [MSFT] 2017-06-13 14:29:02 UTC
The problem is that there's a non-portable pdb as well.


* First try to load the pdb as a portable pdb, which fails gracefully since it's not a portable pdb.
* Then we try to load the pdb as a native windows pdb, which does not fail gracefully, because XI does not support native windows pbds.
* The next step would have been to check for the mdb, but we never get that far because we choke on the native pdb.

Workaround: remove the native pdb file.
Comment 8 Joaquin Jares 2017-06-13 16:23:13 UTC
@Rolf we have always put a regular pdb file there. Is it possible to gracefully fail on native windows pdbs and look for mdbs instead? Also, IMHO, mdb should be the first check, not the last. If an mdb is present it will always be valid, whereas pdb may or may not be valid.
Comment 9 Joaquin Jares 2017-06-13 16:29:27 UTC
Expanding (kept thinking): the other advantage of switching that order is that you will never end up trying a native pdb (unless something is actually broken). We only have native pdbs with mdbs, and never create mdbs for ppdb. So if you check the mdb first, the native pdb that goes with it will be ignored. If there's not mdb at all, the pdb _should_ be portable.
Comment 10 Rolf Bjarne Kvinge [MSFT] 2017-06-14 18:36:00 UTC
The code is from cecil, which is shared between many projects, so I implemented this fix to be as small as possible:


I made cecil not choke on native pdbs when the executable doesn't support native pdbs.
Comment 11 Brendan Zagaeski (Xamarin Team, assistant) 2017-06-14 22:53:24 UTC
*** Bug 57483 has been marked as a duplicate of this bug. ***
Comment 14 Mohak Barokar 2017-06-23 10:37:20 UTC
Verified this Bug on VS 2017 d15.3 Build 

 -Microsoft Visual Studio Enterprise 2017 Preview Version 15.3.0 Preview 2.1
 -Xamarin (a5ed8bf)
 -Xamarin.Android SDK (5f3167a)
 -Xamarin.iOS and Xamarin.Mac SDK (104e7b4)
 Detailed Build Config: https://gist.github.com/mohakbarokar/1c2838f937a87074a75f399f311c35ba

& VS 2015 d15.3 Build

 -Microsoft Visual Studio Enterprise 2015 Version 14.0.25431.01 Update 3
 -Xamarin (a5ed8bf)
 -Xamarin.Android (5f3167a)
 -Xamarin.iOS (104e7b4)
 Detailed Build Config: https://gist.github.com/SumantaWelekar/29f5f6766e8fa13faa7f3a665dfad04c

Mac Agent Build Config: https://gist.github.com/mohakbarokar/4d5b5c3dcb7f972ad039b1daeccc660d

And Breakpoints can be hit in PCL library Test Method.
Hence marking this bug as verified.