Bug 29628 - [XVS.iOS 3.11.445] MDB files are not generated for PCLs and breakpoints in PCLs don't work
Summary: [XVS.iOS 3.11.445] MDB files are not generated for PCLs and breakpoints in PC...
Status: CLOSED DUPLICATE of bug 29890
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: Debugger (show other bugs)
Version: 3.11 (C5)
Hardware: PC Mac OS
: High major
Target Milestone: 3.11.1 (C5SR1)
Assignee: Bugzilla
Depends on:
Reported: 2015-04-30 21:46 UTC by Brendan Zagaeski (Xamarin Support)
Modified: 2017-04-13 17:12 UTC (History)
15 users (show)

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

Test case (38.99 KB, application/zip)
2015-04-30 21:46 UTC, Brendan Zagaeski (Xamarin Support)
Logs, including diagnostic build output (104.06 KB, application/zip)
2015-04-30 21:47 UTC, Brendan Zagaeski (Xamarin Support)
Workaround: patched targets file (4.96 KB, application/octet-stream)
2015-05-02 22:21 UTC, Brendan Zagaeski (Xamarin Support)
Workaround: patched targets file (5.00 KB, application/octet-stream)
2015-05-03 13:43 UTC, Brendan Zagaeski (Xamarin Support)

Description Brendan Zagaeski (Xamarin Support) 2015-04-30 21:46:00 UTC
Created attachment 11004 [details]
Test case

[XVS.iOS 3.11.445] MDB files are not generated for PCLs and breakpoints in PCLs don't work

This is quite similar to bug 28781 on Android, but this problem is now limited to iOS.

Regression status: REGRESSION between Xamarin 3.9.547 (20fd2f0) + Xamarin.iOS (f7736a4) and Xamarin 3.11.445.0 (5061f92) + Xamarin.iOS (6481535)

## Steps to reproduce

1. Open the test case in Visual Studio.

2. Ensure a breakpoint is set on at least one of the lines in `Class1.Foo()` in

3. Build and run the "UnifiedSingleViewIphone1" app in the "Debug|iPhoneSimulator" configuration.

4. Tap the "Button" button.

## Results

The breakpoint in Class1.cs is never hit.

## Expected results

The IDE debugger pauses the app and breaks on the breakpoint in Class1.cs.

The test case works correctly in Xamarin Studio on Mac using the same version of Xamarin.iOS.

## Version information

### Windows 8.1 64-bit, VMWare Fusion 6.0.6 (2684343)

Microsoft Visual Studio Professional 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.6.00057

Xamarin   3.11.445.0 (5061f92)
Xamarin.Android (d23da369e436488f38c8ab8fe8a9ae7d9ea5256b)
Xamarin.iOS (7741cc495ab0baf04ff0405d0604bc27f0ecae2e)

### OS X 10.9.5, MacBook Air

Xamarin.iOS (Business Edition)
Hash: 6481535
Branch: master
Build date: 2015-04-27 04:38:13-0400

Xcode 6.2 (6776), Build 6C131e

Mono 4.0.0 (detached/d136b79)
Comment 1 Brendan Zagaeski (Xamarin Support) 2015-04-30 21:47:18 UTC
Created attachment 11005 [details]
Logs, including diagnostic build output
Comment 2 Brendan Zagaeski (Xamarin Support) 2015-04-30 22:01:04 UTC
Note: if you clean and rebuild the solution, you can get a slightly different (but approximately equally broken) symptom where the `.mdb` file _exists_ but is _incorrect_:

### From the "Output -> Debug" window

> warning: Symbol file /Volumes/Cases/macuser/Library/Developer/
>   CoreSimulator/Devices/FFCADBE1-00FC-45E8-BCD2-6795122B9808/data/
>   Containers/Bundle/Application/EB9A9F2D-0BA9-482F-B635-6CF61669AF04/
>   UnifiedSingleViewIphone1.app/PortableClassLibrary1.dll.mdb
>   doesn't match image (null)
Comment 4 Saurabh 2015-05-01 01:25:04 UTC
I am also able to reproduce this Issue with attached sample using stable builds (XVS 3.11.445, XI and latest builds (XVS 3.11.489, XI on iOS Simulators

Debug Output: https://gist.github.com/saurabh360/07613f6042712744ddd2
VS Trace Log: https://gist.github.com/saurabh360/a380fbfc5662a96d4151
Xamarin Log: https://gist.github.com/saurabh360/75cacf55dec944ae5362
Comment 5 Brendan Zagaeski (Xamarin Support) 2015-05-02 22:21:31 UTC
Created attachment 11034 [details]
Workaround: patched targets file

## Workaround

Copy the attached file into "C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.After.targets"

### Explanation

Based on some little additional tests, it appears the problem is simply that the build process attempts to copy the `.mdb` file for the PCL _before_ the `_ConvertDebuggingFiles` Target has run.

It is therefore possible to work around the problem by adding the following `Copy` Task after the `ConvertPdbToMdb` Task in "Xamarin.iOS.Common.After.targets" (remove the > greater-than symbols from the beginning of each line):

> <Copy SourceFiles="@(_Assemblies -> '%(FullPath).mdb')"
> 	SkipUnchangedFiles="true"
> 	DestinationFolder="$(OutDir)"
> 	Condition="'%(_Assemblies.ResolvedFrom)' != '{TargetFrameworkDirectory}' And '%(_Assemblies.ResolvedFrom)' != 'ImplicitlyExpandDesignTimeFacades' And '%(_Assemblies.FrameworkFile)' != 'true'" />
Comment 6 Margarita 2015-05-03 08:14:31 UTC
Doesn`t work if I use any pre-compiled dlls without any debug symbols *.mdb
Otherwise one should use

> ContinueOnError="true"

And its not really good idea `cause it suppresses other true errors in that task.
Comment 7 Brendan Zagaeski (Xamarin Support) 2015-05-03 13:43:28 UTC
Created attachment 11037 [details]
Workaround: patched targets file

Yes, the workaround from comment 5 also doesn't work in non-Debug builds for the same reason. In retrospect when I posted the workaround, I should have stated a few cautions. Since I'm now posting an updated workaround, I will state those cautions:

A. The workaround is at best only intended as a temporary option until the developers can offer a fix.

B. I'm a member of the Support team, not one of the XamarinVS developers. I'm sure there are ways to make the workaround work more elegantly, but I'm not familiar enough with all of the Targets (and Tasks) to be sure of the cleanest approach.

C. I have only tested this workaround using the _exact_ test case attached to this bug, and only in the default Debug and Release configurations.

## Updated workaround

I think a better way to fix the workaround is to add an `Exists()` condition. So I'm attaching a new modified version of the workaround accordingly (subject to the cautions mentioned above):

> <Copy SourceFiles="@(_Assemblies -> '%(FullPath).mdb')"
> 	SkipUnchangedFiles="true"
> 	DestinationFolder="$(OutDir)"
> 	Condition="Exists('%(_Assemblies.FullPath).mdb') And '%(_Assemblies.ResolvedFrom)' != '{TargetFrameworkDirectory}' And '%(_Assemblies.ResolvedFrom)' != 'ImplicitlyExpandDesignTimeFacades' And '%(_Assemblies.FrameworkFile)' != 'true'" />
Comment 9 Daniel Smith 2015-05-04 22:09:12 UTC
I have updated to Xamarin 3.11.445.0 / Xamarin.iOS and I still see the same issue:  warning: Symbol file xxxxxxxx.dll.mdb doesn't match image (null).  then none of my break points in the PCL work.  This is based on a brand new project from the native portable template - no custom code added by me other than declaring a string and assigning a value in the PCL MyClass constructor so I could set a break point and then creating an instance of MyClass in AppDelegate.
Comment 11 Brendan Zagaeski (Xamarin Support) 2015-05-04 22:23:58 UTC
@Daniel, note that this bug was indeed _originally reported_ against Xamarin 3.11.445.0 (see for example comment 0), so the bug is CONFIRMED to exist in that version.

The "target milestone" field is unfortunately a little confusing:

- The "target milestone" of "3.11" corresponds to 3.11.445.

- The "target milestone" of "3.11.1" corresponds to the _next_ upcoming service release after 3.11.445.

Also note that the bug status of "RESOLVED" is a separate consideration from whether a fix for the bug has been _released_ to an updater channel.
Comment 12 Brendan Zagaeski (Xamarin Support) 2015-05-04 22:28:20 UTC
I'm marking comment 10 as private to remove the keywords in that comment from public searches for this bug report. Comment 10 is discussing an unrelated issue [1].

> [1] https://forums.xamarin.com/discussion/37739
Comment 13 Daniel Smith 2015-05-04 22:55:03 UTC
Thanks for all the clarification - good to know and will help me from clogging up bug reports in the future!
Comment 14 Brendan Zagaeski (Xamarin Support) 2015-05-04 23:00:05 UTC
You betcha!
Comment 15 Antony McKane 2015-05-06 10:29:48 UTC
Can confirm that I too am experiencing this bug.  Oddly enough however it only started today and I updated a few days ago (but debugging has become progressively more troublesome). I must of cleared out the last vestige of the .mdb when I restarted the machine running my iOS Build Host.
Comment 16 Daniel Dickey 2015-05-06 17:27:43 UTC
This is a problem for me as well. Running latest Alpha. Should it be fixed for my version?

Microsoft Visual Studio Professional 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.5.51641
Installed Version: Professional

Xamarin   3.11.507.0 (dfac85e)
Xamarin.Android (cbdf025e886eacb95ce7adf53346961156fae990)
Xamarin.Forms Intellisense   1.0
Xamarin.iOS (7741cc495ab0baf04ff0405d0604bc27f0ecae2e)
Xamarin.iOS Unified Migration   1.0
Xamarin.TestCloud.Integration   1.0
Comment 17 Brendan Zagaeski (Xamarin Support) 2015-05-06 18:50:24 UTC
@Daniel, not yet. I'm tracking the status of the bug's inclusion in the Alpha builds on the release forum thread here:


As you can see, it's not yet in the "Fixes" section.
Comment 18 Akhilesh kumar 2015-05-07 12:04:08 UTC
I have checked this issue with latest C5SR1 builds and now this issue does not exist. On running test project in "Debug|iPhoneSimulator" configuration breakpoints of "PortableClassLibrary1\Class1.cs" hits on clicking button.

Screencast:  http://www.screencast.com/t/MaaaofzWGqKk

Hence closing this issue.

Microsoft Visual Studio Professional 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.5.51641

Installed Version: Professional

Xamarin   3.11.538.0 (36db3f6)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android (2fff837db393f75c4a7a32f5963918dd6168b015)
Visual Studio plugin to enable development for Xamarin.Android.

Xamarin.Forms Intellisense   1.0
Provides intellisense for Xamarin.Forms in the XML editor.

Xamarin.iOS (d8da1911bd2f0f1327a80560a7f286e6e221b0af)
Visual Studio extension to enable development for Xamarin.iOS.

Xamarin.iOS Unified Migration   1.0
Automated migration for Xamarin iOS Classic projects to Unified

Xamarin.TestCloud.Integration   1.0
Early preview of Xamarin Test Cloud integration

XI | Build Host
Comment 19 Akhilesh kumar 2015-05-07 14:02:27 UTC
I have checked this issue for android app also and this is also working fine for android. On debugging application breakpoints of "PortableClassLibrary1\Class1.cs" hits on clicking button.

I have checked it with iOS device/simulator and android device/XAP, x86 and ARM.

Screencast: http://www.screencast.com/t/smKYXG5n
Comment 20 Jose Gallardo 2015-05-10 10:09:38 UTC
*** Bug 29890 has been marked as a duplicate of this bug. ***
Comment 21 Ian Ceicys 2015-05-11 17:43:04 UTC
Bug 29628 is a duplicate of Bug 29890, closing 29628, Bug 29628 is dependent on bug 29886 being fixed.

*** This bug has been marked as a duplicate of bug 29890 ***
Comment 22 Jedat Kinports 2017-04-13 11:41:03 UTC
How can this be done in Xamarin Studio on mac?
Comment 23 Jedat Kinports 2017-04-13 11:43:15 UTC
@Brendan Zagaeski @Comment 7 How can this be done in Xamarin Studio on mac?
Comment 24 Brendan Zagaeski (Xamarin Support) 2017-04-13 17:12:23 UTC
In short, this bug report (and the old workaround in Comment 7) is unlikely to be relevant to Xamarin Studio on Mac at this time.  It is unlikely to be relevant because the original report was specific to Visual Studio on Windows and because the report has been marked as resolved for approximately 2 years and there have been many changes to the targets and tasks over those 2 years.  For any appearances of similar issues recently, please file new bug reports and be sure to include as many details [1] as possible (ideally including a test case).  Thanks in advance!

[1] https://developer.xamarin.com/guides/cross-platform/troubleshooting/questions/howto-file-bug/

If the question is more about authoring MSBuild targets in general, please refer to the MSBuild documentation [2].

[2] https://msdn.microsoft.com/library/0k6kkbsd.aspx

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