Bug 36789 - Xamarin.iOS.Common.After.targets is incorrect -> MDB files are not created -> breakpoints don't work
Summary: Xamarin.iOS.Common.After.targets is incorrect -> MDB files are not created ->...
Status: RESOLVED FIXED
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: Debugger ()
Version: 4.0.0 (C6)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-12-09 18:52 UTC by Evgeniy Zverev
Modified: 2016-12-20 13:43 UTC (History)
8 users (show)

Tags: _XVS1215
Is this bug a regression?: ---
Last known good build:


Attachments
Xamarin.iOS.Common.After.targets failure on creating MDBs (17.82 KB, application/x-zip-compressed)
2015-12-15 12:10 UTC, Evgeniy Zverev
Details


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 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:
Status:
RESOLVED FIXED

Description Evgeniy Zverev 2015-12-09 18:52:40 UTC
Hi

Test machine:
Microsoft Visual Studio Enterprise 2015
Version 14.0.24720.00 Update 1

NuGet Package Manager   3.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

Visual Studio Tools for Universal Windows Apps   14.0.24720.00
The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.

Xamarin   4.0.0.1712 (cdc0365)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android   6.0.0.35 (d300845)
Visual Studio plugin to enable development for Xamarin.Android.

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

Xamarin.iOS.Common.After.targets contents:

	<Target Name="_CollectAssemblies" DependsOnTargets="GetBuiltProjectOutputRecursive">
		<ItemGroup>
			<_ReferencedDlls Include="@(AllBuiltProjectOutputs);" />
			<_Assemblies Include="@(MainAssembly);@(_ReferencedDlls)" />
		</ItemGroup>
	</Target>

If I build a solution of two or more projects, the @(AllBuiltProjectOutputs); list is only filled with the iOS startup project and thus the MDB files are not created for other assemblies which are build within the solution.

As a workaround I replaced the mentioned section with the following:

	<Target Name="_CollectAssemblies" DependsOnTargets="GetBuiltProjectOutputRecursive">
		<ItemGroup>
			<_ReferencedDlls 
				Include="@(ReferenceCopyLocalPaths)" 
				Condition="'%(Extension)' == '.dll' And Exists('%(RootDir)%(Directory)%(Filename).pdb')"/>
			<_Assemblies Include="@(MainAssembly);@(_ReferencedDlls)" />
		</ItemGroup>
	</Target>

which only differs in the way how _ReferencedDlls list is filled.

With this modification all the needed MDBs are created and breakpoints in all assemblies are properly hit.
Comment 1 Joaquin Jares 2015-12-14 17:50:12 UTC
I'm not following your scenario. The general idea of your targets is to generate mdb files for the project you're building and all of its references. MSBuild doesn't really know what the startup project is. What project types do you have in your solution, what's referencing what and for what projects are you missing mdbs? I want to replicate your scenario and try to repro. I may have done something wrong in the targets, but your solution is what I tried to avoid (generating mdbs for projects that don't need them).
Comment 2 Evgeniy Zverev 2015-12-15 12:10:11 UTC
Created attachment 14297 [details]
Xamarin.iOS.Common.After.targets failure on creating MDBs
Comment 3 Evgeniy Zverev 2015-12-15 12:21:40 UTC
I am not quite following your questions. Why not just begin testing the thing from the very basic scenario which clearly shows the fail?
If even that is a problem I describe it.

Examine the attached solution (App3). It consists of:

project #1: App3 (Xamarin.iOS application)
project #2: ClassLibrary2 (Xamarin.iOS class library)

Configuration changes from default:

1. ClassLibrary2 is configured with an output path (..\Bin\) for all configurations.

2. App3 has a reference to the ClassLibrary2 binary.
    <Reference Include="ClassLibrary2">
      <HintPath>..\Bin\ClassLibrary2.dll</HintPath>
    </Reference>

3. In the solution configuration I appended a dependency (App3 depends on ClassLibrary2)

That's it.
Try running the app in Debug/iPhoneSimulator mode. Breakpoints in the App3 work. breakpoints in ClassLibrary2 do NOT work. ClassLibrary2 MDB not generated.

Oh. What a rare and unique case. Truly unobvious one. Clearly a misuse of a perfectly tuned product. Crap.
Comment 4 Joaquin Jares 2015-12-15 13:39:40 UTC
ClassLibrary2 generates its own MDB. It doesn't need the common targets. I'll review later today. That scenario should not be affected by those targets at all. Those targets only exist to generate MDBs for PCLs.
Comment 5 Evgeniy Zverev 2015-12-15 14:13:27 UTC
You say ClassLibrary2 generates its own MDB. Where one can be found after rebuild? Why do the breakpoints not work?

If I provide the workaround described in comment #1 then I can see the MDB for ClassLibrary2 and breakpoints begin working.
Comment 6 Evgeniy Zverev 2015-12-15 14:17:34 UTC
I meant the workaround described in the original description.
Comment 7 Joaquin Jares 2015-12-15 14:20:34 UTC
The fact that ClassLibrary is not generating its own mdb is definitely a bug. 
If your workaround works for you then by all means use it. 

The bug is not in that file, though. I think it's a duplicate of another bug I fixed recently and need to find, that should have already shipped or should be shipping soon. I'll know more when I find that bug or if I'm able to repro.
Comment 8 Evgeniy Zverev 2015-12-15 14:31:26 UTC
After you clarify the situation with the Xamarin.iOS class libraries, are you going to look into the problem further (for PCLs) or should I issue another bug report specific to PCLs with the same repro solution with the only difference that ClassLibrary2 will be a PCL?

I did check that in such a case breakpoints do not get hit now. Workaround helps.

P.S. Is there a really good reason preventing MDBs from generating for everything possible? This may be not a relevant question but the pain from the current situation is not to be ignored as well.
Comment 9 Joaquin Jares 2015-12-15 14:35:14 UTC
Both should be working; I'll review both. 

The problem with generating MDBs for projects that don't need them is that they never get properly cleaned and we may find ourselves in the situation where installing Xamarin is making non-Xamarin projects clean incorrectly and then build incorrectly because of that. We try to never affect anything that has nothing to do with us.
Comment 10 Evgeniy Zverev 2015-12-15 20:28:33 UTC
"We try to never affect anything that has nothing to do with us." sounds ironic to me as long as the "clean" and "rebuild" operations for iOS projects deletes everything from a folder that is selected as an output for the iOS project, either class library or app.

This is out of topic but...just could not stand to put on that. It's a pain either. I have many projects building into a single folder and when working with Xamarin.iOS for VS I carefully avoid rebuilding and cleaning iOS projects. Sometimes I fail and then I have to reload all 418 projects of my solution and rebuild them all. Argh.
Comment 11 Joaquin Jares 2015-12-15 20:30:25 UTC
That's what we're trying to improve on. 418 projects we have never tried, though. It sounds a little excessive :)
Comment 14 Joaquin Jares 2016-12-20 13:43:50 UTC
We implemented this as per the comments. Closing for verification.