This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
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 (show other bugs)
Version: XI 10.10 (d15-2)
Hardware: PC Windows
: High critical
Target Milestone: 15.3
Assignee: Rolf Bjarne Kvinge
: 56893 57483 (view as bug list)
Depends on:
Reported: 2017-05-24 15:23 UTC by Christian.Wall
Modified: 2017-06-23 10:37 UTC (History)
15 users (show)

See Also:
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 Support)

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 Support) 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 Support) 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?


### 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 Support) 2017-06-08 02:28:05 UTC
*** Bug 56893 has been marked as a duplicate of this bug. ***
Comment 7 Rolf Bjarne Kvinge 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 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 Support) 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:

& 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:

Mac Agent Build Config:

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

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