This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 56893 - Unable to hit PCL breakpoints on iOS device in CrossPlatform Xamarin.Forms PCL template
Summary: Unable to hit PCL breakpoints on iOS device in CrossPlatform Xamarin.Forms PC...
Status: VERIFIED DUPLICATE of bug 56808
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: Debugger (show other bugs)
Version: 4.5.0 (15.2)
Hardware: PC Windows
: --- critical
Target Milestone: 15.3
Assignee: Joaquin Jares
: 56781 (view as bug list)
Depends on:
Reported: 2017-05-26 20:41 UTC by Ben Beckley
Modified: 2017-07-04 01:15 UTC (History)
11 users (show)

See Also:
Is this bug a regression?: Yes
Last known good build: XamarinVS (3f99c5a)


Description Ben Beckley 2017-05-26 20:41:13 UTC
XVS (1be4f0c/d15-2)
As the summary says: can't hit breakpoints in a PCL project on device, however they are being hit on simulator.

Reproduction Steps:
1) Create a new CrossPlatform Master Detail Forms PCL app
2) Place a breakpoint in the PCL code (In my case, BaseViewModel Line 31)
3) Allow XMA to connect, change startup project to iOS project, target a device for deployment
4) Deploy to the device
5) Do whatever action is needed to hit the breakpoint (if any)
Expected: Breakpoint is hit
Actual: Breakpoint is not hit

env info:
Comment 1 Adrian Popa 2017-05-30 15:48:09 UTC
Having the same problem.
Comment 2 Brendan Zagaeski (Xamarin Support) 2017-06-01 02:11:17 UTC
## Possible temporary workaround: switch the portable class library project(s) to output "portable" PDB files rather than "full" PDB files

1. Open the portable class library .csproj file in a text editor.  For example, right-click the project in the Solution Explorer and select Unload Project, and then right-click it again and select "Edit ...".

2. Under the PropertyGroup for the "Debug|AnyCPU" configuration, change the DebugType to:

3. Save the change and reload the project.

4. Build, deploy, and start debugging the iOS app project again.

This workaround was successful in my particular test environment using the scenario described in Comment 0, but there might be other scenarios where the workaround will not be effective.

(In Visual Studio 2017, the DebugType setting can also be changed under "Project Properties > Build [tab] > Advanced [button] > Debugging information".)

## Regression status: regression between the Xamarin 15.1 and 15.2 releases

> BAD:  XamarinVS master    (c02a82f) + Xamarin.iOS master     (a6cf8c5e)
> BAD:  XamarinVS (1be4f0c) + Xamarin.iOS (d15-2: d2270eec) "15.2.2 release"
> BAD:  XamarinVS (c871575) + Xamarin.iOS (d15-2: 3e5ac5ff) "15.2   release"
> GOOD: XamarinVS  (3f99c5a) + Xamarin.iOS (d15-1: a04678c2) "15.1   release"

## Additional testing environment info for my tests

### 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 Adrian Frielinghaus 2017-06-01 02:32:48 UTC
I have been struggling with this problem for a while, and I can confirm that switching Debug output on the PCL to "portable" has cleared it up for me.
Comment 4 Brendan Zagaeski (Xamarin Support) 2017-06-01 03:32:01 UTC
*** Bug 56781 has been marked as a duplicate of this bug. ***
Comment 5 Brendan Zagaeski (Xamarin Support) 2017-06-01 03:41:34 UTC
## Cross-referencing note to the Xamarin team

In case it's helpful for various investigation strategies, the test case on related Bug 56808 appears to be an alternate way to trigger the same problem without any involvement of PCL projects or Xamarin.Forms.
Comment 6 buchholz.bastian 2017-06-01 09:09:44 UTC
The problem with this workaround is, that it now does not work on android.

So for iOS debugging we have to set <DebugType>portable</DebugType>
And for Android debugging we have to set <DebugType>full</DebugType>
Comment 7 Brendan Zagaeski (Xamarin Support) 2017-06-02 03:55:00 UTC
> it now does not work on android

Thanks for the note about that result.  It seems that this is due to left-over .mdb debug symbol files.  Long story short, if you manually delete the "bin" and "obj" folders for each of the projects that you have switched to `portable`, uninstall the app from the test device, and then clean and rebuild the solution, that should hopefully allow the `portable` mode to work with Android too.  Once you have performed those clean-up steps once, you should in theory not need to perform them again unless you switch the DebugType again.  (See Bug 57087 for a bit more background information about the issue with stale .mdb files.)
Comment 8 buchholz.bastian 2017-06-02 06:53:32 UTC
Thank you. That did the trick. Now it works on Android and iOS.
Comment 9 Brendan Zagaeski (Xamarin Support) 2017-06-05 23:09:46 UTC
*** Bug 56781 has been marked as a duplicate of this bug. ***
Comment 10 Brendan Zagaeski (Xamarin Support) 2017-06-08 02:25:41 UTC
## Additional workaround step for projects that use `async partial` methods

For users trying the workaround, if any of your library projects contain `async partial` methods, you will hit a bug in the Roslyn C# compiler that causes ""csc.exe" exited with code -532462766" [1].

To work around this error, you can install pre-release version 2.3.0-beta1 or higher of the "Microsoft.Net.Compilers" NuGet package into all of your projects to use the latest Roslyn C# compiler (that includes the fix).

Comment 11 Brendan Zagaeski (Xamarin Support) 2017-06-08 02:28:05 UTC
## Note to the Xamarin team

At the end of the steps in Comment 0, the .mdb file for the PCL is present as expected in the "mtouch-cache/Link" directory, but it is _missing_ from the "mtouch-cache/PreBuild" directory and the final .app bundle.  This matches up exactly with the latest information on Bug 56808.  The problem seems to be caused by recent changes to the `LinkAssemblies()` method in the `mtouch` tool on the Mac.

Based on these results, I will mark this bug as a duplicate of Bug 56808.  Once a candidate fix is available for Bug 56808, it would be good to double-check that the fix is also effective for this Bug 56893.


*** This bug has been marked as a duplicate of bug 56808 ***
Comment 13 Brendan Zagaeski (Xamarin Support) 2017-06-14 18:01:52 UTC
Edited text of Comment 12:

> I have the same problem but in the simulator (didn't test on device).
> The workaround to set "portable" doesn't work. It complains that
> MyApp.dll can't be found and Fody says: And unhandled exception
> ocurred.
> So, this workaround is [ineffective in that case]. We need a solution.

I have marked the original Comment 12 non-public due to vulgarity.
Comment 14 Brendan Zagaeski (Xamarin Support) 2017-06-14 19:57:22 UTC
> this workaround is [ineffective in that case]. We need a solution.
Note that this is issue is still being investigated as a critical issue in Bug 56808 by the engineering team.  The _possible_ temporary workaround provided earlier in this bug was documented in case it might help some users.  It should not be interpreted to mean that the bug has a lower urgency.

> MyApp.dll can't be found
To make a guess, this might be due to an incompatibility of Fody with the portable debugging type in some scenarios.  In case you haven't checked it yet, the diagnostic build output might contain additional information about why the MyApp.dll is not building successfully for your scenario.  There's a chance some of that information would allow you to make another small adjustment that would allow the build process to work successfully while using the portable debugging type.

1. Set "Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity" to Diagnostic.

2. The next time you build the project the diagnostic build output will now be visible in the Output window.
Comment 15 Eric 2017-07-03 18:00:49 UTC
I get the following exception in my .NET Standard library (Target: 1.4 .NET Standard). When the breakpoint is hit.

In the MainActivity of the Droid project I hit the breakpoint and can step through.

Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
System.ArgumentException: Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
   at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count)
   at Mono.Cecil.Metadata.GuidHeap.Read(UInt32 index)
   at Mono.Cecil.MetadataReader.InitializeCustomDebugInformations()
   at Mono.Cecil.MetadataReader.GetCustomDebugInformation(ICustomDebugInformationProvider provider)
   at Mono.Cecil.Cil.PortablePdbReader.Read(MethodDefinition method)
   at Mono.Cecil.Cil.CodeReader.ReadMethodBody()
   at Mono.Cecil.Cil.CodeReader.ReadMethodBody(MethodDefinition method)
   at Mono.Cecil.MethodDefinition.<>c.<get_Body>b__41_0(MethodDefinition method, MetadataReader reader)
   at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TRet& variable, TItem item, Func`3 read)
   at Mono.Cecil.MethodDefinition.get_Body()
   at Mono.Cecil.MethodDefinition.get_DebugInformation()
   at Mono.Debugging.Soft.SoftDebuggerSession.LoadPdbType(TypeDefinition type, Dictionary`2 fileToSourceFileInfos)
   at Mono.Debugging.Soft.SoftDebuggerSession.LoadPdbFile(String assemblyFileName, String pdbFileName)
   at Mono.Debugging.Soft.SoftDebuggerSession.LoadDebugFile(String assemblyFileName, String debugFileName, Func`3 loadDebugFile)
   at Mono.Debugging.Soft.SoftDebuggerSession.CheckBetterMatch(TypeMirror type, String file, Int32 line, Int32 column, Location found)
   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByMethod(MethodMirror method, String file, Int32 line, Int32 column, Boolean& insideTypeRange)
   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByType(TypeMirror type, String file, Int32 line, Int32 column, Boolean& genericMethod, Boolean& insideTypeRange)
   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveBreakpoints(TypeMirror type)
   at Mono.Debugging.Soft.SoftDebuggerSession.HandleTypeLoadEvents(TypeLoadEvent[] events)
   at Mono.Debugging.Soft.SoftDebuggerSession.HandleEventSet(EventSet es)
   at Mono.Debugging.Soft.SoftDebuggerSession.EventHandler()
Comment 16 Brendan Zagaeski (Xamarin Support) 2017-07-03 19:00:37 UTC
> I get the following exception ... When the breakpoint is hit.

This bug is about the specific symptom "Unable to hit PCL breakpoints".  Receiving an _exception_ when hitting a breakpoint is a different symptom from being unable to hit a breakpoint and would need to be investigated in its own bug report.  Particularly if you still see that issue with the latest Xamarin preview or Visual Studio 2017 Preview versions, please submit a new bug report for the issue, ideally including a small self-contained test case that replicates the issue and as many other details as possible about the scenario (see also [1] for additional recommendations).  Thanks in advance!

Comment 17 Eric 2017-07-03 19:29:34 UTC
Ok. I filed a new bug about the Debugger Exception : Thanks for any help!
Comment 18 Brendan Zagaeski (Xamarin Support) 2017-07-04 01:15:43 UTC
## Verification status for the behavior described in Comment 0: verified fixed by the latest Xamarin.iOS "15.3 release" Beta channel preview for the remote Mac

GOOD: Xamarin.iOS (494fcbc)
BAD:  Xamarin.iOS  (104e7b4)

(In keeping with my usual verification procedure, I retested briefly on the "bad" version first to ensure I was still able to replicate the issue on an older version.)

## GOOD Results

The debugger _did_ pause on the breakpoint at BaseViewModel.cs, line 31.

## BAD Results

The debugger did _not_ pause on the breakpoint in BaseViewModel.cs, line 31.

## Additional testing environment info

### Windows

Microsoft Visual Studio Enterprise 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01586

XamarinVS (60c3d0e)

Windows 10 version 1607 (OS Build 14393.0)
US English locale, US Eastern time zone

### Mac

Mono MDK (2017-04/478c04a)

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

### Devices

iPad Mini 2, iOS 8.0

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